{
  "$comment": [
    "全領域の自動化カバレッジ台帳 — 開発以外もすべて同じ物差しで測る。",
    "",
    "【なぜ作るか】2026-08-22時点で、この運用の自動化率について言えたのは",
    "**開発領域だけ**だった（AI完走率76.9% / 変更行のAI比率94.2%）。",
    "マーケティングも経営も『部分実装』としか言えず、どのくらい部分なのかを",
    "数で示せなかった。この台帳はそこを埋める。",
    "",
    "【executor の定義】タスクを**誰が実行しているか**で6分類する。",
    "  ai_autonomous     … AIが起動から完了まで単独。人の承認もゲートも待たない",
    "  ai_executes_gated … AIが実行するが、ゲート（CI・上限・品質基準）を通ったときだけ通る。",
    "                      人の個別承認は不要。**この運用の主力はここ**",
    "  ai_proposes       … AIは提案・下書き・検知まで。適用/実行は人間",
    "  human_only        … 人間が実行。AIは関与しない（または意図的に関与させない）",
    "  nobody            … 誰もやっていない（未実装）",
    "  intentional_no    … 意図的にやらない。分母から外す",
    "",
    "【4つの率を必ず並べて出す】分母を1つに決めると必ず都合のよい数字になる。",
    "  総合自動化率 = (autonomous + gated) / 定義タスク      … nobody を分母に含む。最も厳しい",
    "  AI実行率     = (autonomous + gated) / 実施中タスク    … nobody を除いた分母",
    "  AI関与率     = (上記 + proposes)    / 実施中タスク",
    "  カバー率     = 実施中タスク         / 定義タスク      … そもそも誰かがやっている割合",
    "**総合自動化率とカバー率を隠して AI関与率だけ出すのが、この台帳で一番やってはいけないこと。**",
    "",
    "【この測り方の限界（先に書く）】",
    "  1. **タスク数の重み付けが粗い。**「記事の実装」と「SBOM生成」が同じ1として数えられる。",
    "     開発領域には変更行という別の物差しがある（AI 94.2%）が、他領域には無い。",
    "     したがって領域間の比較は**傾向**であって、精度のある比較ではない。",
    "  2. **タスクの粒度が領域で揃っていない。** 法人経営は外部レビューの列挙をそのまま",
    "     採ったため粒度が粗く、マーケは実装単位まで細かい。前者が低く出るのは事実だが、",
    "     粒度の差も混ざっている。",
    "  3. **evidence が無い分類は主張として弱い。** ai_autonomous / ai_executes_gated は",
    "     証跡ファイルを持つことを CI が強制する（scripts/automation-rate.mjs --check）。",
    "",
    "【出典】タスクの列挙は docs/autopilot-maturity-backlog.md（外部レビュー由来）と、",
    "本セッションで実測した内容。分類は3リポジトリの実装を1件ずつ当てて決めた。",
    "",
    "【blocker / unblocked_by / unlock（2026-08-26追加）】",
    "AI が実行していないタスクには **なぜ実行していないか** を必ず持たせる。",
    "無いと総合自動化率は『残りぶん実装すれば埋まる』と読まれるが、実際には",
    "**大半が実装量ではなく外部データ・鍵・権限境界・検出力で止まっている。**",
    "分類は scripts/autonomy-gap.mjs の BLOCKERS が正で、CI がそれ以外の値を落とす。",
    "policy_boundary と physical_human は **オーナーが境界を動かさない限り到達しない**。",
    "この2つを到達可能側に数えるのが、この台帳で二番目にやってはいけないこと。",
    "",
    "unlock は解除条件のまとまり。**1タスク＝1作業ではない** —— ASCのレポートが降りれば",
    "複数件が同時に動く。個別に積むと順番を間違えるので、解除する行為のほうを単位にする。"
  ],
  "measured_at": "2026-09-15",
  "known_limits": [
    "タスク数の重み付けが粗い（全タスクが等価に数えられる）",
    "タスク粒度が領域間で揃っていない（法人経営は粗く、マーケは細かい）",
    "開発領域の変更行比率94.2%に相当する客観指標が他領域には無い",
    "返金検出1件は、2026-09-13の明示承認によりテストでの運用準備完了と本番自動監視で計上。本番の返金初回検出やApple Sandbox REFUNDの完走実績ではない。返金の条件変更時点の比較は159/176=90.340909%（後続の月次予算・課金回復準備の加点前）。",
    "返金検出と課金失敗回復の2件は、所有者指定のテスト済み運用準備＋稼働確認済み本番監視で計上。本番の初回返金・初回課金回復は未観測。課金回復準備直前は161/177=90.960452%、直後162/178=91.011236%。この2件を実例必須として除いた参考値は160/176=90.909091%。",
    "返金検出・課金失敗回復・障害案内の3件は、所有者指定のテスト済み運用準備＋稼働確認済み本番監視で計上。本番の各初回は未観測。障害案内準備直前162/178=91.011236%、直後163/179=91.061453%。3件を実例必須として除いた参考値は160/176=90.909091%。案内APIの正常応答は全利用者への到達や法的通知完了を意味しない。"
  ],
  "tasks": [
    {
      "area": "① 次期機能開発",
      "task": "ビジョン文書の維持（機能追加の必読ゲート）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/qa/check_vision.py",
        "../simplememo-ios/docs/VISION.md",
        "../simplememo-ios/.github/workflows/qa-static.yml",
        "CLAUDE.md",
        "../simplememo-api/CLAUDE.md",
        "../simplememo-ios/CLAUDE.md"
      ],
      "note": "2026-08-22実装。**参照と鮮度を機械が守る。**3リポジトリの CLAUDE.md が「設計に入る前に読め」と指す唯一の文書なのに、**参照が壊れても誰も落ちなかった** — 壊れたことは「読んだ人が違う節を読んで帰る」という形でしか現れず、しかもその人は自分が違う節を読んだことに気づかない。初回の実行で1件出た: 冒頭が「最後の『12. 機能追加時のチェック』が実際のゲート」と書いていたが §12 は「現在地」で、チェックは §13。**読者を1つ手前の節へ送っていた**（3リポジトリのCLAUDE.mdはどれも §13 と正しく書いており、間違っていたのはこの文書の自分自身への参照だけだった）。節番号の解決・必須節の存在・**現在地が90日を超えたら落とす**・未決定が空でないこと、の4つ。4通りとも壊した状態を作って落ちることを確認した。残る弱さ: **中身が正しいかは見ていない**（ビジョンの正しさは機械には決められない）。定期改訂そのものは人が書く — 機械がやるのは古くなったことを言うところまで",
      "since": "2026-08"
    },
    {
      "area": "① 次期機能開発",
      "task": "AIが変更してはいけない安全原則の固定",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/docs/VISION.md",
        ".github/workflows/seo-check.yml"
      ],
      "note": "VISION §9「作らないもの」＋§13の6問。claude.ymlのactions:write非付与"
    },
    {
      "area": "① 次期機能開発",
      "task": "要望・レビュー・問い合わせ・競合情報の重複排除",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/signal-ledger.json",
        "scripts/check-signals.mjs"
      ],
      "note": "2026-08-22実装。要望・レビュー・問い合わせ・競合・利用実態を1台帳に統合し、dedupe_key で同じ話を1行にする。**声の大きさを「何回転記されたか」で測らないため。**実際「送信の確実性」は問い合わせ・レビュー実測・アンケートの3経路から来ており、台帳を作るまで別々の紙に載っていた。declined は理由が無いとCIが落ちる",
      "since": "2026-08"
    },
    {
      "area": "① 次期機能開発",
      "task": "期待効果・確信度・工数・リスクによる自動優先順位付け",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/feature-backlog.json",
        "scripts/feature-score.mjs",
        ".github/workflows/seo-check.yml"
      ],
      "note": "2026-08-22実装。**確信度は evidence_strength から機械的に決まり、手で置けない**（主観にすると順位はいくらでも動く）。リスクは点数を下げるのではなく承認を要求する — 掛け算にすると期待効果が大きければ危険な案が1位になる。根拠が弱い候補は「やらない」ではなく「まず測る」に落ちる"
    },
    {
      "area": "① 次期機能開発",
      "task": "ユーザー要望の受領と未処理の検知",
      "executor": "ai_autonomous",
      "evidence": [
        "../simplememo-ios/scripts/asc_metrics.rb",
        "../simplememo-ios/.github/workflows/asc-metrics.yml",
        "scripts/review-intake.mjs",
        "data/review-intake.json"
      ],
      "note": "2026-08-22実装。App Store レビューを日次で取り込み、**未処理が14日を超えたらCIが落ちる**。受け取っただけで放置される状態を検知する。台帳は取り込みと同日に作ったので空から始まる — **空であること自体は異常ではなく、取り込みが動いたあとも空のままなのが異常**。日次実行そのものは run 32599889435（2026-08-22 21:32 UTC・event=schedule）で発火を確認済み"
    },
    {
      "area": "① 次期機能開発",
      "task": "受領した要望の設計への落とし込み",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/docs/reports/feature_requests_2026-07-31_obsidian_user.md",
        "docs/designs/obsidian-nested-destinations.md",
        "data/feature-backlog.json",
        "scripts/feature-score.mjs",
        "scripts/roadmap.mjs",
        "docs/verified-design-execution-2026-09-06.md"
      ],
      "note": "AIが設計文書まで。採否はオーナー判断。**受領（機械）と分けたのは、片方だけ自動化されている状態を1行に潰さないため。**混ぜると『要望を受け取れているか』と『設計まで自動か』が同じ1行になる\n\n**[2026-08-28] 到達可能側から外した（分類の訂正）。**設計文書までは機械が出しており、残っているのは**採否の判断**。そこは実装量では動かない。\n**害は件数ではなく向きに出る** —— `--plan` が「作れば進む」と言い続け、天井が実際より高く出る。到達可能な件数は減るが、**下がった天井のほうが本物。**\n\n[2026-09-06] オーナーの最大権限委譲を受け、Codexが実際の要望と現行コードを照合しfolder_pick_uxの設計を採用した。feature-scoreの実CLIで受入条件と文書をバックログへ保存し、ロードマップにも反映する。権限表に設計採否の条項を追加したため、恒久的なオーナー待ちという従来の前提を解除する。公開と出力の検証が済むまでexecutorはai_proposesのまま。これは機能の実装・App Store公開の完了ではない。\n\n[2026-09-06 実行検証] PR1029のhead 18d63f2f6894d805e1e1bedc2bf5dfb24af68bdbはSEO Validation run 34028777897を通り、main c4a3b856aa262e9630ccba8c92a828802a095592へマージ。本番Pages 226ddeac-8c3d-4f4f-ba2c-620e5f179c18もsuccess。mainから実行したfeature-scoreとroadmapの両出力で、folder_pick_uxのAIによる設計採用と受入条件・文書への参照を確認した。実際に受領した要望の設計採否をAIが実行し開発計画へ適用したため、この業務をai_executes_gatedへ移す。機能そのものの実装・App Store公開・効果検証は別工程で、完了扱いにしない。",
      "authority": {
        "domain": "機能要望の設計採否",
        "ai_may": "リスクタグのない既存候補の設計採用"
      },
      "since": "2026-09"
    },
    {
      "area": "① 次期機能開発",
      "task": "継続率データによる優先度判断",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/docs/reports/RETENTION_MONETIZATION_COHORT_2026-07-29.md",
        "../simplememo-api/src/analytics/aso-cohort.ts",
        "../simplememo-api/scripts/retention-evaluation.py",
        "../simplememo-api/.github/workflows/retention-evaluation.yml",
        "../simplememo-api/data/retention-evaluation.json"
      ],
      "note": "D7継続2.5〜3.7倍を根拠に優先度決定。決定は人\n\n2026-09-06: D1の成熟した獲得コホートを既存管理APIから読み、D28→D7→初日保存の順に95%区間の分離で調査優先度を決定する日次経路を本番化。https://github.com/simplememofast/simplememo-api/actions/runs/34016315646 が成功。今回は悪化を支持する差が無いためcontinue_measurement。機能採否・因果効果・解約率の判定ではない。初回HTTP403はクライアント識別ヘッダーを修正して解消し、失敗時は写しを更新しない。集計は非公開リポジトリ内に保持。",
      "since": "2026-09"
    },
    {
      "area": "① 次期機能開発",
      "task": "PRD・受入条件・UX・多言語の作成",
      "executor": "ai_executes_gated",
      "evidence": [
        "docs/prd/TEMPLATE.md",
        "docs/prd/undo-last-capture.md",
        "scripts/check-prd.mjs"
      ],
      "note": "[2026-08-26] docs/prd/TEMPLATE.md に定型を置き、scripts/check-prd.mjs が守る。VISION §13 の6問は**見出しがあるだけでは通らない**（各問に本文が要る）。受入条件はチェックボックス、多言語は JA/EN 両方、§1 の主張には出典。\n\n**いちばん効くのは §6「決めていないこと」。**PRD は提案であって決定ではないので、ここが空だと PRD が黙ってオーナー判断を代行できる。本当に何も無いなら「無い」と書く —— **書かないことと、無いことを分ける。**\n\n**ゲート付き実行**なのは、PRD の中身の是非は人がPRで見るから。機械が守るのは「定型を満たしていること」まで。1本目は docs/prd/undo-last-capture.md（★5レビュー 2026-07-07 が根拠、オーナー判断4件を §6 に残してある）"
    },
    {
      "area": "① 次期機能開発",
      "task": "Issue→ブランチ→PR→テスト→配信を結ぶ共通実行ID",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/autopilot-runs.json",
        "scripts/autopilot-runs.mjs"
      ],
      "note": "2026-08-22実装"
    },
    {
      "area": "① 次期機能開発",
      "task": "遠隔操作できるFeature Flag",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/SimpleMemo/FeatureFlagRollout.swift",
        "../simplememo-ios/SimpleMemo/FeatureFlags.swift",
        "../simplememo-api/src/config.ts"
      ],
      "note": "[2026-08-22訂正] 「アプリ本体に無い」は誤りだった。v4.7から WPFlag 15個が /v1/config 経由で遠隔操作できていた。同日、段階公開・キャッシュ期限・取得経路のテストを追加。**④の同名タスクだけ訂正して、この①側を直し漏らしていた**"
    },
    {
      "area": "① 次期機能開発",
      "task": "対照群・最低サンプル数・停止条件を持つ実験基盤",
      "executor": "ai_executes_gated",
      "evidence": [
        "growth/experiments/experiments.json",
        "growth/lib/ledger.mjs",
        "growth/scripts/check-experiments.mjs"
      ],
      "note": "2026-08-22実装。open な実験は control.kind（holdout/pre_post/none）・min_sample・stop_conditions が無いとCIが落ちる。**対照群が無いこと自体は禁じていない** — 無いのに書かないことを禁じている。pre_post には confounders を必須にした（書かないと因果を主張しているのと同じ）",
      "since": "2026-08"
    },
    {
      "area": "① 次期機能開発",
      "task": "D7/D28・課金・解約まで含む評価",
      "executor": "ai_proposes",
      "evidence": [
        "../simplememo-api/docs/reports/FUNNEL_EVALUATION_2026-08-20.md",
        "docs/subscription-observation-evidence-20260910.md",
        "../simplememo-api/docs/verified-retention-evaluation.md"
      ],
      "note": "2026-09-10: API PR #306で既存の日次Retention Evaluationへ同一インストールコホートの購読状態・配信済みライフサイクル事実を接続し、本番workflow 34440775851の成功と保存artifactを確認した。対象2週はいずれも元の初回起動contextが未計装で、既定のProduction/QA除外を適用すると適格コホートが空だった。評価はcontinue_measurement、解約率・LTVはnullのまま。実装済みだが評価に必要な観測が揃っていないため、executorはai_proposesのままで加点しない。",
      "blocker": "verification_pending",
      "unblocked_by": "既存の日次retention-evaluationで、元の初回起動がrelease/ios_deviceとして観測された同一コホートを追い、成熟した保存D7/D28、購読との対応、更新・失効・返金の実観測、未成熟・未計装・不明状態を照合する。旧usage集計とは母数が異なるので混ぜない。完全な課金/解約履歴と発生率はなお未計測であり、状態在庫・復元済み価格・通知カテゴリの合算で代用しない。Search Consoleの蓄積待ちやコードの存在だけで完了にしない。",
      "unlock": "bq_28d"
    },
    {
      "area": "① 次期機能開発",
      "task": "失敗機能の自動停止とバックログ差し戻し",
      "executor": "ai_autonomous",
      "evidence": [
        "../simplememo-api/src/rollout-guard.ts",
        "../simplememo-api/test/rollout-guard.test.ts",
        "docs/canary-testflight.md"
      ],
      "note": "ガードレール指標が有意かつ実害を伴って悪化したら kill を自律実行する（承認を挟まない＝可逆で安全な方向のため）。2026-08-22実装。**同日、kill が実機まで届いて機能が消えることを TestFlight で実証した**（docs/canary-testflight.md の実測）。ただし**押したのは人であってガードではない**。ガードの自動判定は本番でまだ1回も発火していない — TestFlight の人数では min_installs_per_cohort:30 に届かない。**止められることと、判断できることは別**。バックログ差し戻しは未実装"
    },
    {
      "area": "① 次期機能開発",
      "task": "判断理由と結果のDecision Ledger",
      "executor": "ai_autonomous",
      "evidence": [
        "docs/obsidian/AUTOPILOT_LOG.md",
        "growth/experiments/experiments.json",
        "data/autopilot-runs.json",
        "../simplememo-api/src/rollout-guard.ts",
        "../simplememo-api/test/rollout-guard.test.ts"
      ],
      "note": "機能開発の判断も入るようになった（カナリアガードが判定・根拠・実行有無を毎回KVへ記録する）。**2026-08-22実装。本番でまだ1回も発火していない**（段階公開中のフラグがゼロのため）。実装した≠動いた"
    },
    {
      "area": "① 次期機能開発",
      "task": "本番改善サイクルの完走（機能側）",
      "executor": "nobody",
      "evidence": [
        "data/feature-outcomes.json",
        "data/obsidian-feature-observation-20260911.json",
        "docs/obsidian-feature-observation-20260911.md"
      ],
      "note": "機能側の完走は0件。2026-09-06に階層保存先の指標・分母・28日観測・固定評価日2026-10-18を出荷前に宣言済み。2026-09-11のASC照合で公開5.8.46/1179に実装が含まれ、段階公開開始2026-09-08T17:13:59Zと確認したため「宣言なし・未出荷」という旧記述を更新した。最初の本番D1診断では書き込み成功59件・失敗3件のすべてで比較属性が欠落。内部端末除外前の診断値であり、成功率や改善効果を主張しない。直下経路の計測修正・後続版の事前宣言・正式評価が必要。カナリア安全ガードの一周と機能の宣言→出荷→測定→判定→学習の完走は別であり、今回の照合・修正に加点しない。",
      "blocker": "verification_pending",
      "unblocked_by": "原計画の28日観測（公開開始アンカーから2026-10-06T17:13:59Zまで）と2026-10-18の固定評価日に、集計SQL・対象版・内部端末除外・属性欠損・母数・判定・学びを照合する。欠損を直下と推定しない。修正版の評価は別途出荷前に宣言する。",
      "unlock": "impl_product"
    },
    {
      "area": "① 次期機能開発",
      "task": "North Star Metric（Zero-decision Capture Rate）の実測",
      "executor": "nobody",
      "evidence": [
        "docs/nsm-measurement-resumption-20260911.md",
        "docs/nsm-watch-participation-readiness-20260920.md"
      ],
      "note": "**定義はあるが実測が無い。**`../simplememo-ios/docs/VISION.md` が究極KPIとして定義し、CLAUDE.md も「Zero-decision の数値はまだ実測が無い。実測が出るまでサイトに数値を書かない」と明記している。**つまり最上位のKPIだけが、他の全指標に課している基準を満たしていない。**優先順位付けは代理指標（継続率・課金率）で回っており、NSMは判断に効いていない\n2026-09-11: 完成済み計測案にCapture前の全入力監視を必須化する余分な条件があることを敵対的レビューで確認。VISIONに沿った前向き計測契約へ訂正し、全受付・失敗・欠測を保持した実装を再開する。定義修正やテストだけでは実測へ加点しない。\n2026-09-20: 計測契約の同意照合（iOS PR604）と認証情報を渡さない準備（API PR360）は統合済み。Watchの明示的参加・端末間撤回（iOS PR605）は415件のローカル試験、修正後レビュー、5つの統合検査を通過してmainへ統合済み。検証対象81a0ac1と統合先84cf8fedの変更21ファイルの一致を確認した。内部検証の実装・試験であり、同一配布版の全入口・保存先QA、各本人の実同意、本番参加経路、実データと全受付の照合は未完。実測を開始・完了したことにせず、nobodyと元の受入条件を維持する。",
      "blocker": "not_started",
      "unblocked_by": "非空保存要求の受付を設定・上限判定前に全入口で記録し、受付台帳と操作順序・当時の保存指示・実配送結果を照合する。母数不明はnull、既知の欠測は同じ分母の不明として保持する。旧案の入力前witness待ちではなく、同一配布版での全入口検証と実収集まで進める。",
      "unlock": "impl_measurement"
    },
    {
      "area": "① 次期機能開発",
      "task": "機能の削除・単純化・高速化の候補化",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/feature-backlog.json",
        "scripts/feature-score.mjs",
        "scripts/roadmap.mjs",
        "docs/designs/email-setup-simplification.md"
      ],
      "note": "2026-09-07: 本番の認証コホート（英語14 install中Apple provider_error 6、初回起動から48h未満のエラー後メモ送信0）を根拠に、初期設定の手入力導線を単純化する候補email_setup_primary_manualをAIが登録・採点した。Apple/Googleの削除は根拠不足として不採用。改善効果は未測定なのでhypothesis、5×0.15÷2=0.375、登録時12位・「まず測る」。既存のfeature-scoreと13週roadmapの出力へ接続し、SEO Validationを通して記録する。完了範囲は候補化と優先付けのみ。製品への採用、実装、出荷、改善効果、本番改善サイクルの完走には流用しない。過去の『追加の候補しかない』『28日蓄積まで候補化不能』という停止理由は、初期設定の実測を起点とする今回の候補には当てはまらない。定着率の悪化や認証エラーの根本原因は断定していない。",
      "since": "2026-09"
    },
    {
      "area": "① 次期機能開発",
      "task": "週次・月次・四半期ロードマップの自己生成",
      "executor": "ai_autonomous",
      "evidence": [
        "scripts/roadmap.mjs"
      ],
      "note": "[2026-08-26] scripts/roadmap.mjs が13週の窓を台帳から組み立てる。**日付を発明しない** —— 台帳に評価日があるものだけを暦に置き、順番しか決まらないもの（解除条件の梯子・機能バックログ）は順番だけ出す。オーナーの手数が要るものを機械の側と混ぜない（混ぜると「機械だけで届く」の主張が壊れる）。\n\n**週次の粒度は出していない。**台帳が週単位の日付を持たないため、週の欄を作ると構造のほうを発明することになる。この行の note が名指ししていた欠落は「次の四半期を機械が組み立てる経路が無い」で、そこは埋めた。週次が要るとわかったら別の行として足すこと。"
    },
    {
      "area": "① 次期機能開発",
      "task": "過去の失敗を参照して同じ提案を繰り返さない",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/operating-memory.json",
        "scripts/check-operating-memory.mjs",
        ".github/workflows/seo-check.yml"
      ],
      "note": "2026-08-25実装。learning に lesson_key を持たせ、**同じ key が2回出たらCIが落ちる。**2回目が出た＝1回目の学習が成果物に効かなかった、ということなのでそこで気づける。**実際にこの仕組みが無かった間に、同じ失敗が7回並んだ**（growth の基準値未記録7件）。**seed 6件はすべて後追い記録**なので、発生時記録が溜まるまで「再発を防いだ実績」は主張できない"
    },
    {
      "area": "② バグ修正",
      "task": "監視カバレッジの棚卸し",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/monitoring-coverage.json",
        "scripts/check-monitoring.mjs"
      ],
      "note": "2026-08-22実装。13系統を棚卸しし、**検知器が実在するか**と**実際に起きた障害種別に検知経路があるか**をCIが確かめる。『全部見ています』ではなく『何が空いているか』を言うための台帳"
    },
    {
      "area": "② バグ修正",
      "task": "統合監視（Crash/API/Watch/課金/問い合わせ）",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/monitoring-coverage.json",
        "scripts/check-monitoring.mjs",
        "../simplememo-api/src/inquiry.ts",
        "../simplememo-api/src/watch-health.ts",
        "../simplememo-api/src/analytics.ts",
        "../simplememo-api/src/autopilot-report.ts",
        "../simplememo-api/test/ops-alerts.test.ts",
        ".github/workflows/autopilot-health.yml",
        ".github/workflows/cron-health.yml",
        "../simplememo-ios/scripts/qa/check_analytics_crossrepo.py",
        "../simplememo-ios/data/analytics-server-allowlist.json"
      ],
      "note": "2026-08-22。棚卸しで名指しした穴3系統を、**2つの流れが別々に塞いだ。**main側で**課金とWatch同期**（データは既に取れていて閾値と通知だけが無かった）、こちら側で**問い合わせとWatch同期**（受け口はあったが来たことに気づく経路が無かったので、未応答の滞留を日報に載せた）。合流時点で**3系統とも埋まっている。**\n\nWatchは検知器が2つになった。**毎時は install 単位**（件数で見ると3秒間隔でリトライする1台が群全体を動かす — 実測で7 installが712件）、**日報は24h窓の件数と手動修復**（分母20件未満では判定しない。毎日「異常」が出る検知器は読まれなくなる）。\n\n**どちらの検知器も「読めなかった」を 0件 と書かない** — 混ぜると穴が「異常なし」に見える。\n\n[2026-08-22追記] **計測の事故が起きる境目**（iOS↔relay のイベント名）に検査を足した。従来の検査は「サーバに登録したのに iOS 側のセットに入れ忘れる」だけを見ており、**逆向き（iOSが送るのにサーバの allowlist に無い）は素通り**していた。その場合サーバは受け取って黙って捨て、端末には200が返るので送信側にも症状が出ない。サーバ allowlist の写しを iOS 側に置いたので**隣のリポジトリが無いCIでも動く** — 隣を見に行く形にすると検査が常にスキップされ、事故は起きたまま緑になる",
      "since": "2026-08"
    },
    {
      "area": "② バグ修正",
      "task": "問い合わせから再現テストを自動生成",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/docs/qa/REGRESSION_TEST_TEMPLATE.md",
        "../simplememo-api/src/inquiry.ts",
        "../simplememo-api/.github/workflows/repro-facts.yml",
        "../simplememo-ios/SimpleMemoTests/VoiceAutoStartLifecycleTests.swift",
        "../simplememo-ios/data/voice-review-repro-case.json",
        "docs/product-review-repro-execution-20260909.md"
      ],
      "note": "2026-09-09、実App Storeレビューと関連修正からCodexが製品再現XCTest・Issue455を生成。iOS PR456の最終SHAのCI成功後、main 14a7ba37a7a2e1ebf99a0e6f199c2f6ef2c87dadへ適用。最終7件成功、過去の2つの挙動では各1件失敗、原本復元後の成功を確認。音声認識ハードウェアの復旧や常時生成サービスの完了は含めない。",
      "unblocked_by": "本文は依然 D1 にあり読めない。**2026-08-26 に端末/OS/版/分類だけを本文抜きで数える経路を作った**（simplememo-api: summarizeReproFacts / migrations/0027）。残るのは (a) 移行0027の適用、(b) その集計が日報の文面ではなく**リポジトリ側から読める形**で出ること、(c) 母数 — inquiries は現在0件\n\n**[2026-09-03 訂正] (a) と (c) は、どちらも済んでいた。**\n\n**(a) 移行0027 は 2026-08-27 22:17 に適用されている。**欠けていたのは `d1_migrations` の台帳行のほうで、DDL は当たっていた。`simplememo-api/migrations/historical/2026-09-01_backfill_d1_migrations_0026_0028.sql` が**スキーマ側で確認**してそう書いている（`device` cid 12 / `os` cid 13 が在る）。2026-09-03 時点で `migrations list --remote` は「適用するものは無い」。\n\n**(c) inquiries は0件ではない。**`simplememo-api/docs/email_intake.md` が実データの `email_hash` を並べ、同一差出人・同一分類で `auto_replied` が 0 → 1 に遷移したのを**独立に2回**記録している。\n\n**したがって残るのは (b) だけで、それは実装。**`blocker` を `external_data` から `not_started` へ移した —— **外部データを待っているのではない。**待ちに数えたままだと `--plan` がこの行を「材料が来ていない」側に置き続け、**実装で届くものが待ちに見える。**\n\n**executor は動かさない。**まだ何も出ていない。そして着手の前に設計判断が1つ要る —— **取り出し口をどこに置き、誰が読むか。**relay の管理鍵は「本番の管理鍵を、日次の可視化のためだけに別リポジトリの CI へ広げない」と定められており、simplememo は公開リポジトリ。\n\n**[2026-09-03 続き] (b) の出口を作った（simplememo-api#236）。**\n\n    GET /admin/repro-facts              機械が読む口（Bearer ADMIN_API_KEY・読むだけ）\n    .github/workflows/repro-facts.yml   日次で取り込み data/repro-facts.json へ\n\n**日報の文面を剥がす経路は作らなかった** —— 表示を直した日に集計が壊れる形になるため。\n\n**取り込むのは simplememo-api（非公開）自身。**`ADMIN_API_KEY` は元からあちらにしか無く、`data/release-materials.json` の「**本番の管理鍵を、日次の可視化のためだけに別リポジトリの CI へ広げない**」に触れない。このリポジトリ（公開）は置かれた JSON を読むだけでよい。\n\n**3つの状態を潰していない** —— `ok`（0件を含む）/ `migration_pending` / `unreadable` を欄にし、`facts` は ok のときだけ入る。取得に失敗した回は写しを置き換えない。\n\n**blocker を `not_started` から `verification_pending` へ。**作るものは無くなったが、**まだ1周も走っていない。**executor は据え置く。\n\n**[2026-09-04 訂正] 直前の欄は言い過ぎだった。**「作るものは無くなった。残っているのは1周動いたのを見ること」と書いたが、**それは材料の話で、この行の題名の話ではない。**\n\n    行が言っていること   問い合わせから再現テストを**自動生成**する\n    実際に作ったもの     端末/OS/版/分類の**数え上げ**を機械が読める形に置いた\n\n**材料が読めるようになっただけで、生成はしていない。**この行の note は元から「手動運用」と書いてあり、そこは変わっていない。`data/repro-facts.json` が1周置かれても、**executor は動かない** —— 動かせば、していないことを「している」と数えることになる。\n\n**blocker を `verification_pending` から `not_started` へ戻す。**「作ったが1周見ていない」のは**材料の経路**であって、この行そのものではない。残っているのは、その材料から**再現テスト（と Issue）を実際に作る側**。\n\n**(a)(b)(c) を「残るのは」と並べていた元の欄も、そこが甘かった。**3つとも材料の条件で、**生成が要ることは1行も書いていなかった。**満たしても題名は満たされない。\n\n**[2026-09-05] ⑧ は動かした。この行は据え置く。**\n\n`simplememo-api/.github/workflows/classifier-gaps.yml` が実データで1周し、**実物の問い合わせから回帰テストと Issue が自動でできた**（⑧の欄に実測を書いた）。同じ仕組みは題名の上ではこの行にも当たるように見える。\n\n**それでも動かさないのは、この行が「② バグ修正」の下にあるから。**証跡は iOS の `REGRESSION_TEST_TEMPLATE.md`、note は「Watch同期4往復→v4.9.30」で、**指しているのは製品バグの再現**であって relay の分類器の欠陥ではない。分類器を材料に満たしたと数えるのは、**題名ではなく仕組みのほうに合わせて読む**ことになる。2026-09-04 にこの2行で一度その読み方をして外している。\n\n**残っているのは、製品バグの再現に足りる材料。**いまアプリが送る診断は端末/OS/版まで（#238）で、**何をしたら起きたか**が無い。そこが入れば同じ生成側に載る。\n\n[2026-09-09 実行] 材料は実App Storeレビューから取得できた。レビューの事実と過去修正から導出した操作を区別し、実Composeの起動・背景・復帰を通す製品テストをAIが生成した。Issue455/PR456・最終CI成功・main適用まで完了。根拠は docs/product-review-repro-execution-20260909.md。⑧の分類器や過去の音声修正自体を再加点せず、この新しい製品再現テスト生成の1実行だけをai_executes_gatedへ移す。",
      "since": "2026-09"
    },
    {
      "area": "② バグ修正",
      "task": "Unit / UI / 契約テストの実行",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/.github/workflows/qa-ios.yml"
      ],
      "note": "XCTest/XCUITest＋Watchブリッジ契約テスト2コピー＋parity CI"
    },
    {
      "area": "② バグ修正",
      "task": "Visual Regression Test",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/qa/check_screenshot_baseline.py",
        "../simplememo-ios/scripts/qa/verify-screenshots.py",
        "../simplememo-ios/data/screenshot-baseline.json",
        "../simplememo-ios/.github/workflows/qa-static.yml"
      ],
      "note": "2026-08-25実装。**撮影と内在的な検査は前からあったが、前回と比べる経路が無かった** —— artifacts/ は .gitignore で追跡0件なので基準が1回も残らず、ボタンが動いても文字が切れても「PNGとして妥当で寸法が揃っている」限り通っていた。画像ではなく**指紋（12x24の平均輝度・288整数）**を置く（重さと差分の読めなさを避ける）。sha256 は1画素で別物になるので使えない。**Pillow も足していない**（同じファイルの純Python PNGデコーダに載せた）。しきい値6.0は self-test で実測 —— 1画素 0.00 で鳴らず、ボタン大の矩形 8.96 で鳴る。**撮影は macOS が要るので ubuntu の CI からは見えない。**見えないときは形だけ検査し、**『差が無い』とは書かない**（review-intake の judged と同じ）。**基準はまだ空** —— 次に Mac か Xcode Cloud で撮って --update を1度回すと入る。変化＝失敗ではなく、落ちるのは『動いたのに基準を更新していない』場合だけ"
    },
    {
      "area": "② バグ修正",
      "task": "オフライン・タイムアウト・500・429の決定論再現",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/docs/qa/AUTOMATED_QA_ARCHITECTURE.md",
        "../simplememo-ios/SimpleMemo/QA/QAStubURLProtocol.swift"
      ],
      "note": "QAStubURLProtocol。低速回線とバックグラウンド復帰は無い"
    },
    {
      "area": "② バグ修正",
      "task": "実機/シミュレータでの操作・撮影・計測",
      "executor": "ai_executes_gated",
      "evidence": [
        "docs/obsidian/AUTOPILOT_RUNBOOK.md",
        "../simplememo-ios/SimpleMemoUITests/ArticleScreenshotUITests.swift",
        "../simplememo-ios/scripts/qa/capture-article-screenshots.sh",
        "../simplememo-ios/scripts/qa/summarize_xcresult.py",
        "../simplememo-ios/data/qa-capture-2026-09-06.json"
      ],
      "note": "macOS必須。Runbook §7「できないこと」の筆頭\n\n**[2026-08-28] 前提が広すぎた。ただし覆ってはいない。**「macOSが要る＝人間だけ」と書いてあるが、**macOSの経路は2つある** —— GitHub Actions の macOSランナー（予算保護でAIは起動しない）と、**Xcode Cloud（Apple側の課金で、GitHubの予算とは別勘定）**。後者は自動で走っている: simplememo-ios#239（2026-08-27）に `SimpleMemo | PR Check | Build - iOS` が success で出ており、**人は何も触っていない。**起動と診断のAPI経路も在る（scripts/xcode_cloud_start_build.rb / xcode_cloud_diagnose.rb）。\n\n**それでも覆せない。**同じPRに出たのは Build だけで、**UIテスト（SimpleMemoQA / SimpleMemo-iOS-PR）は出ていない。**docs/qa/XCODE_CLOUD_ONE_TIME_SETUP.md はそれを『PR Check の合格に必要』と書いているので、**書いてあることと実際が食い違っている**（変更ファイルで起動条件が絞られているのか、アクションが外れているのかは、ASCの鍵が無いのでここでは確かめられない）。撮影のほうは docs/qa/ARTICLE_SCREENSHOTS.md が『ローカルMac』での通し実行しか記録していない。\n\n**したがって分類は動かさない。**言えるのは「人間だけ」の理由が予算保護だけではないことと、**この食い違い自体が確かめるべき対象**だということ\n\n2026-09-06: CodexがローカルMacの専用iPhoneシミュレータで撮影UIテストを実行。操作・可視性assert・3枚の撮影・出力・寸法計測・画像確認を完了。1テスト成功/失敗0、70.480秒、1206x2622。新規ビルドは空き容量不足で停止したため5.8.14/build1の既存テスト成果物を利用し指紋を記録。最新版5.8.20の検証、実機、音声認識精度、AirPods/Watch確認には広げない。状態バーが黒くサイズも記事基準超過のため記事掲載は未承認。専用シミュレータは終了後に削除。GitHub macOS QAは起動せず、実機での事前確認は別行のまま。",
      "since": "2026-09"
    },
    {
      "area": "② バグ修正",
      "task": "アクセシビリティ・文字切れ・多言語の自動検査",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/qa/check_localization.py",
        "../simplememo-ios/data/localization-baseline.json",
        "../simplememo-ios/.github/workflows/qa-static.yml",
        "scripts/seo-check.js"
      ],
      "note": "2026-08-22。**多言語だけアプリ側にも入った。**初回の実行で3件出た（どれも目視では見つからない）: NSLocalizedString の直接呼び出し2箇所（キーが無い言語では`onboarding.page2.apple_signin.error_generic` という文字列がそのままエラーとして表示されていた）/ premium.* 5キーが全10言語で二重定義（50行、後の行が静かに勝つので先の行を直しても画面は変わらない）/ premium.unlimited がどの言語にも無い。全部直した。**未翻訳では落とさない**（8言語が46.3%なのは既知）が、基準線から下がると落ちる。残る弱さ: **文字切れとアクセシビリティはアプリ側で未検査。**文字切れは実機のフォントとレイアウトが要り、文字数比での近似は誤検出だらけになるので採らなかった（ドイツ語が日本語の3倍は正常）",
      "since": "2026-08"
    },
    {
      "area": "② バグ修正",
      "task": "性能・起動時間の計測",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/launch-health-monitor.ts",
        "../simplememo-api/src/autopilot-report.ts",
        "../simplememo-api/test/launch-health-monitor.test.ts",
        "../simplememo-api/docs/launch_health.md",
        "data/monitoring-coverage.json"
      ],
      "note": "2026-08-22。**本番の常時監視になった。**それまでは段階公開中だけガードが見ており、平常時に起動が壊れても気づく経路が無かった。指標も読み方の文書も既にあり、**無かったのは毎日それを見る仕組み**だけだった（POSTを叩いた日にしか読まれていなかった）。判定は文書の読み方をそのまま機械にした: **比率をそのまま閾値にしない** — iOSは毎フォアグラウンド復帰で breadcrumb を上書きするので、正常利用後のkillでもlaunch_incomplete が出る（scene_did_become_active は恒常的に最多で実害の証拠にならない）。**前段ステージが1件でも出たら分母を問わず劣化**、比率は前週比の跳ねだけに使う。残る弱さ: **起動「時間」は測っていない。**0.4秒は今も定点実測で、本番の起動所要時間を集める経路はiOS側に無い。ここが監視しているのは完走したかどうかだけ",
      "since": "2026-08"
    },
    {
      "area": "② バグ修正",
      "task": "依存脆弱性・秘密情報・SBOM・署名検査",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/scripts/check-supply-chain.mjs",
        "../simplememo-api/data/sbom.json"
      ],
      "note": "2026-08-22実装（simplememo-api）。SBOM 259件（**実行時はわずか1件**、残り258は開発時）・integrity欠落0件・秘密情報スキャン。**値は出力しない**（出力に秘密を写したら意味が無い）。**既知脆弱性の照合（npm audit）は意図的に含めない** — 外部DB依存でCIの合否が日替わりになり、やがて無視されるため",
      "since": "2026-08"
    },
    {
      "area": "② バグ修正",
      "task": "Fuzz / Property-based / Mutation Test",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/property-tests.mjs",
        "scripts/autopilot-gate.mjs",
        "scripts/autopilot-budget.mjs"
      ],
      "note": "2026-08-22実装。実行判定と予算集計の**不変条件12件**を、種を固定した乱択400ケース／件で検査する。ドリル（26の具体例）が守れない**書かなかった組み合わせ**を踏むのが目的。変異テストで検出力を確認（forceが予算を飛び越える／認証切れが予算の陰に隠れる、をどちらも検出）。**アプリ側のfuzzは未実装**",
      "since": "2026-08"
    },
    {
      "area": "② バグ修正",
      "task": "失敗の分類（独立2モデル監査）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/qa/ai_triage.sh"
      ],
      "note": "2026-08-22実装。割れたら人間に上げる"
    },
    {
      "area": "② バグ修正",
      "task": "回帰の合否判定（決定論的）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/docs/qa/AUTOMATED_QA_ARCHITECTURE.md",
        "../simplememo-ios/SimpleMemoTests/QATestCase.swift",
        "../simplememo-ios/SimpleMemoTests/RelayClientContractTests.swift"
      ],
      "note": "AIには判定させない設計"
    },
    {
      "area": "② バグ修正",
      "task": "セキュリティ監査と修正",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/docs/reports/SECURITY_HARDENING_2026-07.md",
        "../simplememo-ios/SimpleMemo/AnalyticsClient.swift",
        "../simplememo-ios/SimpleMemo/DraftManager.swift",
        "../simplememo-ios/SimpleMemo/ObsidianManager.swift"
      ],
      "note": "AIが発見しAIが修正。High 1件含む4件 **[2026-08-27] 証跡を報告書から修正した実物へ移した。**報告書は「見つけた」の記録であって「直した」の記録ではない。3ファイルは報告書 §が名指ししている修正先"
    },
    {
      "area": "② バグ修正",
      "task": "カナリア公開と自動ロールバック",
      "executor": "ai_autonomous",
      "evidence": [
        "../simplememo-api/src/rollout-guard.ts",
        "../simplememo-api/test/rollout-guard.test.ts",
        "docs/canary-testflight.md"
      ],
      "note": "露出群/対照群を bucketOf で復元して比較し、悪化なら自動で撤回する。2026-08-22実装。**同日、kill が実機まで届いて機能が消えることを TestFlight で実証した**（docs/canary-testflight.md の実測）。ただし**押したのは人であってガードではない**。ガードの自動判定は本番でまだ1回も発火していない — TestFlight の人数では min_installs_per_cohort:30 に届かない。**止められることと、判断できることは別**"
    },
    {
      "area": "② バグ修正",
      "task": "誤修正率・再発率・MTTRの計測",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/autopilot-runs.json",
        "scripts/autopilot-runs.mjs"
      ],
      "note": "2026-08-22に検知時刻を投入。検知まで中央値2.1h/最大50.7h、修理まで中央値0.9h。誤修正率・再発率はまだ"
    },
    {
      "area": "② バグ修正",
      "task": "基盤故障の検知と自己修復",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/autopilot-selfheal.mjs"
      ],
      "note": "2026-08-22実装。レーンF"
    },
    {
      "area": "② バグ修正",
      "task": "不要になったテストの整理",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/SimpleMemoTests/PaywallAnnualEmphasisTests.swift",
        "docs/test-retirement-2026-09-07.md"
      ],
      "note": "テストを**足す**経路はある（回帰テスト化の実績あり）が、**減らす／直す経路が無い。**flaky を検出する仕組みも、使われなくなったテストを見つける仕組みも3リポジトリに無い。放置すると『赤いのが普通』になり、②の検査群全体の信頼が落ちる\n\n[2026-08-26] blocker を not_started → statistical_power へ。未使用テスト検出は**対象が0件**（.test.mjs 2本は両方CI配線済み）で、作っても一度も発火しない検査になる。flaky 検出は反復実行の履歴が要る。**母数が無いものを「検出できる」と数えない。**\n\n[2026-08-27] **この項目を割った。**元は「flakyテスト・不要になったテストの整理」で1件だったが、上の 08-26 の測定自身が2つを別々に論じている（未使用テスト検出＝対象0件 / flaky検出＝履歴が要る）。**片方だけ実測で動いたので、動いた分をここから出した**（② テストの順序依存の検出）。こちら（不要になったテスト）は**対象0件という測定を否定していない**ので据え置き。\n\n[2026-09-07 実行] iOS PR #400で、独立したtestBothEmphasisModesApplyWithoutCrashを表示状態のマトリクス検査へ統合し廃止した。旧表示検査と合わせた2メソッドを1メソッドに整理（クラス9件→8件）。両モード×文字あり/nil/空文字/空白、および旧スモーク固有のsecondary/nil→recommended/nil切替を明示的に検査し、残る7件は維持。最終head d2a2735413e57b72be723d82cba7cb5e5c4a6a14でローカル8/8・スキップ0、Xcode Cloud Build/FastUnit、static/parityがすべて成功。2026-09-07T10:09:30Zにc1d5984710554a1c2125b76728062abecaad9a6fでマージ済み。旧「対象0件」は8月のweb検査の観測であり、今回のiOSの整理対象を否定しない。全リポジトリの未使用テスト自動検出や実機QAの完了は主張しない。既存タスク1件の実行開始として記録し、テスト修正一般や順序依存検出には重ねて加点しない。",
      "since": "2026-09"
    },
    {
      "area": "② バグ修正",
      "task": "テストの順序依存の検出",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/scripts/check-test-isolation.mjs",
        "../simplememo-api/test/test-isolation.test.ts",
        "../simplememo-api/.github/workflows/ci.yml",
        "../simplememo-api/test/verify-start-cooldown.test.ts"
      ],
      "note": "2026-08-27実装。**台帳のここには「flaky 検出は同一コミットの反復実行の履歴が要り、いまその履歴を持っていない」と書いてあった。順序依存については、それは誤りだった。**履歴は要らない —— `--sequence.shuffle` を種を固定して当てれば、確定的に出る。\n\n実際、履歴ゼロで本物を1件出した。`npm test` が **1770件すべて緑**の状態で、シャッフルすると3種すべてで1件落ちた: `verify-start-cooldown` の「cooldown 中は送らない」—— 7/7インシデント(R2)の番人。\n\n**落ち方が肝。**`expect(status).toBe(429)` は通っており、落ちたのは`expect(fetchSpy).not.toHaveBeenCalled()` だけだった。テスト側の `ctx.waitUntil` がPromise を捨てる空実装で、本番の Cloudflare はこれを待つので**モックがランタイムより緩かった。**捨てられた送信が宙に浮き、**次のテストの fetch スパイに着弾していた** —— 「送らないこと」の検証が、順序次第で他人の送信を数えていた。\n\n**この穴は機械が1件も出していなかった**（手で shuffle を当てて見つけた）ので、ci.yml の `npm test` 直後に配線した。種は固定（既定 1,2,3）——毎回ランダムに振ると CI が設計上ときどき落ちるものになり、直そうとしている病気そのもの。\n\n**限界を数えている。**見つかった1件は5種中2種でしか露出せず、3種なら見逃す確率は約22%。出力に「緑は『順序依存が無い』ではない」と明記した。打ち切りも「異常なし」にしない（上限5分・実測15秒の20倍。上限2秒にして発火を確認済み）。\n\n**この項目が見ているのは順序依存だけ。**実行ごとに結果が変わる真のランダム flaky は別で、そちらは依然として反復実行の履歴が要る。\n\n**since を明示している。**証跡に `ci.yml` と `verify-start-cooldown.test.ts`（どちらも以前から在るファイル）が含まれるので、`min(証跡の初出月)` だと **2026-07 に自律していたことになる。**実際に動き出したのは 2026-08-27。**遡って自律度を盛らない。**",
      "since": "2026-08"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "検索データの取り込み（GSC / BigQuery）",
      "executor": "ai_executes_gated",
      "evidence": [
        "growth/scripts/ingest-bigquery.mjs",
        ".github/workflows/seo-daily.yml"
      ],
      "note": "日次自動"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "データ鮮度の監視",
      "executor": "ai_executes_gated",
      "evidence": [
        "growth/scripts/bq-preflight.mjs"
      ],
      "note": "鮮度落ちで失敗する"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "API障害・停止・欠測からの自動復旧",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/recover-ingest.mjs",
        "data/ingest-recovery.json",
        ".github/workflows/seo-daily.yml"
      ],
      "note": "2026-08-26実装。**分類はもう出来ていた**（bq-preflight.mjs が6通りに分ける）のに、その分類ごとに手を打つ側が無く、落ちた回は要約を人が読むまで何も起きなかった。機械が取るのは4つ: 再試行（指数バックオフ）／退避（直近のgoodスナップショット）／劣化継続（退避先が7日より古ければ新規記事を止めて保守回へ）／欠測の記録。**preflight の落ちる・落ちないは変えていない** — 変えたのは落ちた後。翌朝のレーンFが未修理の故障としてこれを拾う。**まだ本番で発火していない**（data/ingest-recovery.json は空）。確かめてあるのは判断の論理だけで、`--selftest` が9通りの分類と「退避先が無いのに退避したことにしない」「鮮度が足りていれば止めない」を実際に落として確認する",
      "since": "2026-08"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "資格情報失効からの復旧（再同意・鍵の再発行）",
      "executor": "human_only",
      "evidence": [
        "scripts/recover-ingest.mjs",
        "data/credential-expiry.json"
      ],
      "note": "API障害からの自動復旧と、資格情報失効時の再同意・鍵の再発行は別業務として維持する。2026-09-14、所有者の明示承認に基づき、既存のApple Ads組織への再同意とAppsFlyer側の設定保存をAIが実行した。再同意そのものを恒久的な人の操作とは扱わない。一方、その後の実照合でも下流の接続はInvalid credentials、データ受信はNeverのままであり、正常復旧は確認できていない。再同意の実施だけで回復済みとせず、executorと正式スコアは据え置く。recover-ingest.mjsの既存チェックや各利用者本人の同意境界は変更しない。",
      "blocker": "verification_pending",
      "unblocked_by": "再同意と設定保存は承認済みで実施済み。既存連携の正常な接続結果と実データ受信を確認し、失効から復旧までの実行証拠を揃える。同じ再同意を反復せず、下流状態の変化または新しい診断根拠に基づいて進める。",
      "since": "2026-08",
      "unlock": "credential_recovery_verified"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "施策の選定（レーンA〜E）",
      "executor": "ai_autonomous",
      "evidence": [
        "docs/obsidian/AUTOPILOT_RUNBOOK.md",
        "scripts/autopilot-gate.mjs",
        "growth/scripts/build-queues.mjs"
      ],
      "note": "ノイズフロア・品質ゲートに基づきAIが単独で選ぶ **[2026-08-27] 証跡を手順書から選定を実際に行うスクリプトへ移した。**RUNBOOK は「こう選ぶ」であって「選んだ」ではない"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "記事の実装と内部リンク配線",
      "executor": "ai_executes_gated",
      "evidence": [
        "docs/obsidian/AUTOPILOT_LOG.md"
      ],
      "note": "出荷10件すべてAIが執筆。人は中身に触っていない"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "OG画像の生成",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/generate-og-batch.js"
      ],
      "note": "Playwright。毎回自動"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "デスクトップQRの生成と検証",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/generate-qr-codes.mjs"
      ],
      "note": "35件を独立デコード検証"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "品質ゲート（ノイズフロア・品質80点・検証規約）",
      "executor": "ai_executes_gated",
      "evidence": [
        "docs/obsidian/AUTOPILOT_RUNBOOK.md",
        "growth/scripts/build-queues.mjs"
      ],
      "note": "「毎日出すために基準を下げる」を失敗と定義 **[2026-08-27] ノイズフロアを実際に計算しているのは build-queues.mjs。**RUNBOOK は基準の記述"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "本番デプロイ（検証済みSHAのみマージ）",
      "executor": "ai_executes_gated",
      "evidence": [
        ".github/workflows/auto-merge.yml"
      ],
      "note": "SEO Validation合格時のみ"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "停止の検知（緑のまま何もしていない）",
      "executor": "ai_executes_gated",
      "evidence": [
        ".github/workflows/autopilot-health.yml",
        ".github/workflows/cron-health.yml"
      ],
      "note": "12:00と07:00の二重"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "ahrefs / AppsFlyer / Firebase のデータ連携",
      "executor": "nobody",
      "evidence": [],
      "note": "自動連携なし。手動エクスポート\n2026-09-09実照合: AppsFlyerの鍵待ちは解消済み。残るサービスと継続取得の条件はdocs/execution-priority-review-20260909.md参照。部分取得・空データでexecutorを動かさない。",
      "blocker": "external_credential",
      "unblocked_by": "AppsFlyerの既存集計APIは2026-09-09にHTTP200で32行取得済み。Ahrefsの認証済み画面は取得可能だが継続API連携は未確認。FirebaseのiOS分析はデータ未受信で、iOS mainにAnalytics収集の実装がない。3サービス全体の取得・取込・継続実行を揃える。WebのGA4をiOSのFirebase観測へ代用しない。",
      "unlock": "analytics_vendors"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "App Store Connect のデータ連携",
      "executor": "ai_autonomous",
      "evidence": [
        "../simplememo-ios/scripts/asc_metrics.rb",
        "../simplememo-ios/.github/workflows/asc-metrics.yml",
        "../simplememo-ios/data/appstore/asc-metrics.json",
        "../simplememo-ios/scripts/asc_analytics.rb",
        "../simplememo-ios/.github/workflows/asc-analytics.yml",
        "growth/scripts/ingest-asc.mjs",
        "growth/data/appstore/README.md"
      ],
      "note": "2026-08-22実装。日次で取り込む（GETのみ）。**受け皿だけだったのは「ASCにエクスポートAPIが無い」という誤った前提が README に書かれていたため。**実測: レビュー8件・平均4.63を取得。ASO漏斗と購入は Analytics のレポート15種を要求済み。**[2026-08-25] instance は 10/15 まで出ている**（08-23・08-24 の2日ぶん。asc_metrics.rb の reports_with_data）。**ただし取得側は1件も落とせていなかった** —— asc_analytics.rb の欠陥2件（schedule 実行で ASC_REPORTS が空文字になり取得対象が空／既定の語 \"Sales\" が156件のカタログに0件一致）で、**毎日0件を緑で出荷していた**（run 32844534637 の実ログ「取得対象 0 件（部分一致: ）」）。2026-08-25 に修正済みだが、**次回の定時実行までは依然として0件のまま。**この経路を ai_autonomous と数えているのは『日次で自動的に走ること』についてであって、『データが降りていること』についてではない（data/operating-memory.json om-2026-08-25-asc-zero）。入金額（proceeds）だけは /v1/salesReports が必要で vendor number 未登録のため取れない。**「日次」は 2026-08-22 21:32 UTC に初めて実際に発火して裏が取れた**（run 32599889435 / event=schedule → コミット 35b8df4）。それまでは手動1回しか実績が無く、この欄の『日次』は書いただけの状態だった。この回で Analytics 要求は作り直されず既存を再利用している（created_now: false・要求IDは同一）ので、**毎日新しい ONGOING 要求が積み上がる形にはなっていない**。\n\n経路は2本ある。**metrics（asc_metrics.rb）が上記の実測を出している側**で、**Analytics Reports（asc_analytics.rb → growth/scripts/ingest-asc.mjs）は読む側の配線**。後者は **Sales and Trends ではなく Analytics Reports を使う** — 前者は vendorNumber が要り管理画面にしか無いが、後者はアプリIDだけで足りるのでオーナー作業ゼロで始められる。取り込みは**行そのものを置かず、列名・行数・日付範囲・数値列の合計・名指しした分類列ごとの内訳だけ**（個人が特定できる列が将来増えたときに気づかず貯め始めるのを防ぐ）。**[2026-08-26] 内訳を足した** —— それまで保存していたのは数値列の合計だけで、`Cancellation Reason` のような文字列の列は**列名だけが残って中身は毎回捨てられていた**（om-2026-08-26-discarded-not-missing）\n\n**[2026-08-26] 読む側が付いた。**それまでこの行が指していたのは取得だけで、落ちてきた列のうち実際に読んでいたのは数値列の合計だけだった。`Event` / `Source Type` / `Page Type` / `Download Type` / `Territory` は**届いたまま毎日捨てていた**（⑨解約理由と同じ欠陥。名指しした分類列に③の分を入れ忘れていた）。取得側の内訳に③⑥の列を足し、読む側を ../simplememo-ios/scripts/asc_funnel.rb として日次に配線した（別行「ストア内漏斗の観測」）",
      "since": "2026-08"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "AIプローブ（生成AI検索での露出確認）",
      "executor": "ai_executes_gated",
      "evidence": [
        "growth/input/AI_PROBE_PROTOCOL.md",
        "scripts/ai-visibility-probe.py",
        ".github/workflows/ai-visibility-probe.yml",
        "data/ai-visibility-probe.json"
      ],
      "note": "月1・オーナーが手動\n\n2026-09-06: 5固定質問をリポジトリ文脈無しの独立CLIセッションで実検索し、tool_use/tool_resultの成功対応を照合する週次経路を本番化。https://github.com/simplememofast/simplememo/actions/runs/34016914073 が成功。全5問有効・検索呼び出し6件、非指名4問の本文言及0件・自社引用2件（旧言及数は引用URL誤認のためPR #1002で訂正）、実費0.238017ドルを費用台帳へ記録。Claude Sonnetのみの新系列であり、旧手動3社比較の継続ではない。Q5は言及率から除外。予算不足・検索未実行・不完全回答は成功に数えない。観測結果と実費はPR #997で公開。",
      "since": "2026-09"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "言及・競合ウォッチ",
      "executor": "ai_executes_gated",
      "evidence": [
        "growth/scripts/check-mentions.mjs",
        "growth/data/mentions/",
        "growth/data/mentions/README.md",
        "docs/obsidian/AUTOPILOT_RUNBOOK.md",
        ".github/workflows/seo-check.yml"
      ],
      "note": "2026-08-22。スナップショットが1件だけだった状態から、**2件目を実際に取り、やらなかった週に落ちる検査を入れた。**手順書は「週1回・前回が7日以上前なら実行」と書いていたが、**その条件を誰も検査しておらず、実際に10日空いていた**（3日の遅れは誰にも見えていなかった）。検査は (1) 最新の古さ (2) **過去の間隔**（最新だけ見ると途中の空白が隠れる）(3) READMEの固定クエリが欠けていないか — 一部だけ検索して「やった」ことにすると**系列は連続しているのに中身が変わり**、あとから「あの週から言及が減った」に見える (4) 前回との差分が書かれているか、を見る。5通りとも壊して落ちることを確認した。**検索そのものはセッションのWebSearchで行う**（CIからは実行しない）ので、実行はAI・遅れの検知はCI、という分担。残る弱さ: **本文はフェッチしていない**（この環境のegress制限）。mentions_us は検索結果の要約だけを根拠にしており、中身の妥当性は機械には判定できない",
      "since": "2026-08"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "トレンドレーダー（Googleトレンド/はてブ/ランキング）",
      "executor": "ai_executes_gated",
      "evidence": [
        "docs/trend-radar-prompt.md",
        "docs/obsidian/AUTOPILOT_RUNBOOK.md",
        "scripts/trend-radar.py",
        ".github/workflows/trend-radar.yml",
        "data/trend-radar.json"
      ],
      "note": "2026-08-22にRunbook §6の保守メニューへ組み込み。PR起案の判断は人\n\n2026-09-06: Google JPトレンド・はてブIT・App Store生産性ランキングの取得、前回差分、失敗保持、観測PRまで自動化。main実行 https://github.com/simplememofast/simplememo/actions/runs/34015632069 が成功し、観測PR #995を経て公開JSONのrun_url/status=okを確認。記事採否や外部投稿まで自動化したとは数えない。",
      "since": "2026-09"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "PR企画の採点とゲート判定",
      "executor": "ai_executes_gated",
      "evidence": [
        "growth/scripts/d-score.mjs"
      ],
      "note": "算数とゲートの矛盾をCIが落とす。採点は人が置く"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "PR原稿の執筆",
      "executor": "ai_autonomous",
      "evidence": [
        "docs/pr-autopilot-2026-09.md",
        "scripts/check-pr-facts.mjs",
        "data/code-authorship.json"
      ],
      "note": "本原稿がその実例 **[2026-08-27] 執行面の証跡は「生成器」ではない。**原稿を書くのはセッションであってスクリプトではないので、機械側に残るのは (a) 原稿を落とす事実検査と (b) 著者がAIであることの台帳の2つ。**生成器が無いことをここに書いておく**"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "PR原稿の事実・数値・引用元の検査",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/check-pr-facts.mjs",
        "data/site-constants.json",
        "data/benchmark.json"
      ],
      "note": "2026-08-22実装。site-constants.json と benchmark.json を正として、旧アプリ名・古い起動時間・廃止済みトライアル・誇大表現・価格ドリフトをCIが落とす。**引用元の確認（出典が実在するか）はまだ人**"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "ヒーロー画像の生成",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/generate-pr-hero.mjs",
        "data/pr-claims.json"
      ],
      "note": "2026-08-22実装。1200x630（G1ゲート）をPlaywrightで生成し、**出力の実寸を検証する**（生成できたかではなく出た画像で判定）。文言は data/pr-claims.json から読むので、**主張検査を通っていない見出しの画像は原理的に作れない**。裏の取れていない主張があるときは既定で生成を拒否し、--allow-unsupported を付けた場合だけ DRAFT リボン付きで出る"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "PR TIMES への配信操作",
      "executor": "human_only",
      "evidence": [
        "data/authority-matrix.json",
        "scripts/press-release-next.mjs",
        "data/press-release-next.json",
        "docs/ai-execution-999-2026-09.md"
      ],
      "note": "2026-09-09: 今回の企業182412・下書き10の配信操作はAIへ委任済み。同日夜の最新ユーザー目標で配信前の条件が99.9%から99.497%へ変更された。未配信の1件が残っても198/199=99.497487%なら数値条件を満たせるため、旧circular_prerequisiteをverification_pendingへ訂正する。現在は実測156/179で未達・未配信なのでexecutorはhuman_onlyを維持。保存・承認・条件変更は加点しない。実測99.497%以上と品質・本文・宛先・日時・料金条件をすべて満たして実配信・公開確認を行う。PR TIMES上書きは前回検証済み保存から+3ポイント以上（目標到達時の最終同期を除く）。本人同意など他の未完了業務は変更しない。\n\n2026-09-11: 最新ユーザー目標を99%超へ反映。blocked_onのatLeastは必要条件だけで、最終のevaluateDispatchは未丸めの率 > 0.99を必須とする。分類・実行証拠・未配信状態は変更しない。\n\n2026-09-12: 最新ユーザー指示で目標を98%超へ更新。必要条件のatLeastは0.98、最終判定は未丸めの率 > 0.98。今回の条件変更を加点せず、実配信・公開読戻しまでhuman_onlyを保持する。",
      "blocker": "verification_pending",
      "unblocked_by": "追加承認は不要。未丸めの実測98%超を反映した配信前スナップショットとevaluateDispatchの全条件を満たした後に配信し、公開URL・本文・日時を確認する。未配信分を先取り加点しない。",
      "authority": {
        "domain": "プレスリリースの配信",
        "ai_may": "次回リリース202609-autonomy-followup（企業182412・下書き10）の配信前検査と、全条件通過後のPR TIMES配信操作"
      },
      "$previous_note": "管理画面から手動。APIが無い **[2026-08-27 オーナー判断]「お金周りを除いて渡す」の対象。**境界は外れたので、残るのは**権限ではなく実装**。ただし宣言では終わらない —— 権限表は不可逆な領域の承認を外すのに machine_gate（実在する checker／export された関数／kill switch／正の日次上限／材料が無いときは止まる）を要求するので、**ゲートができるまで権限表の該当行は承認制のまま**。\n\n**[2026-08-28] 到達可能側から外した（分類の訂正）。**権限表「プレスリリースの配信」は `requires_approval: true`、human_only に「PR TIMES管理画面からの配信操作」「配信可否の判断」の2つを置いている。機械ゲートは無い（＝承認を外す例外に入っていない）。\n**害は件数ではなく向きに出る** —— `--plan` が「作れば進む」と言い続け、天井が実際より高く出る。到達可能な件数は減るが、**下がった天井のほうが本物。**",
      "blocked_on": [
        {
          "file": "data/press-release-next.json",
          "path": "snapshot.ai_execution_rate",
          "atLeast": 0.98
        }
      ],
      "unlock": "pr_dispatch_verified"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "キャンペーンパラメータの付与",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/tag-cta-placements.js",
        "data/cpp-map.json"
      ],
      "note": "CIが強制。49件がpage-level ct=保持"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "App Store CPP（訴求別ページ）の実験",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/cpp-map.json",
        "../simplememo-ios/scripts/lib/asc_product_pages.rb",
        "../simplememo-ios/scripts/qa/test_asc_product_page_weeks.rb",
        "../simplememo-ios/docs/reports/cpp-evaluation-20260915/REPORT.md",
        "../simplememo-ios/docs/reports/cpp-evaluation-20260915/evidence.json",
        "../simplememo-ios/docs/reports/cpp-evaluation-20260915/asc-ui-readback.json",
        "docs/cpp-execution-evidence-20260915.md"
      ],
      "note": "34本作成済みだが実験として回っていない\n\n[2026-09-07 実測更新] 非公開iOS側PR #401/#402で日次とApple生成の週次Detailedを取得し、日付・ページ・イベント/Download Typeの組み合わせを保持した。mainの取得run 34111401528と34112630725は成功。観測されたCPPのダウンロードセルは更新、DiscoveryセルはImpressionであり、初回DL・ページ閲覧による実験評価には使えなかった。未観測セルは0ではない。実験の完了や効果は加点しない。ページ本数の旧34本は履歴で、2026-09-05の非公開棚卸しは70本（公開済みと下書きが混在）。\n\n[2026-09-15 実行確認] ASCの認証済みCPP画面で、完結した共通期間2026-09-07〜09-13（UTC）の初回DLとページ閲覧を直接観測し、obsidian-vaultとmail-to-selfの記述的比較を完了した。比較対象、流入元の違い、表示回復・英語/QR導線・本文変更の同時施策を非公開iOS側に保存。元の解除条件は月次DetailedまたはASC CPP画面の一次指標・共通期間・比較対象・同時施策であり、今回の実行が満たした。因果効果・獲得向上は判定できず、欠測は未知のまま。事前の価値契約や効果成功の加点はしない。既存1業務をnobodyからゲート付きAI実行へ移し、業務の追加・分割・除外や算式変更はしない。初回DL等の数値と選択済み画面本文は非公開iOS側に保持する。",
      "$previous_unblocked_by": "取得経路は本番稼働済み。日次・週次の周辺合計を初回DLやページ閲覧へ読み替えない。次は月次DetailedまたはASCのCPP画面で一次指標の観測可否を確認し、共通の対象期間・比較対象・同時施策を記録する。初回DL・閲覧・比較の根拠が揃うまで実験完了へ移さない。数値は非公開iOS側に保持する。",
      "since": "2026-09"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "SNS投稿（X日本語）",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/x-japanese-execution.json",
        "docs/x-japanese-execution-20260909.md"
      ],
      "note": "2026-09-09: 旧scheduled API経路の停止とX日本語投稿自体を混同していた。9月5日の包括公開委任後、CodexがX Webで本文・日時・対象の一意性を検査して予約・改稿を保存し、9月7日12:15 JSTに公開された。私的ツール呼び出しログと実投稿2096799366464094302の本文・アカウント・日時を照合。9月9日に公開本文を再確認。個別の最終本文承認は不要だった。旧API経路は再開せず、既存の日本語投稿業務1件だけを移管する。表示回数やDR効果は数えない。",
      "authority": {
        "domain": "SNS投稿（X・TikTok）",
        "ai_may": "承認済み投稿群のX Web日本語ブランド投稿（AIが最終本文・日時を判断し、照合後に公開・予約・公開確認）"
      },
      "since": "2026-09"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "SNS投稿（X英語・TikTok）",
      "executor": "intentional_no",
      "evidence": [
        "README.md"
      ],
      "note": "アカウントBAN／品質未達で運用停止中"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "リスティング広告の運用",
      "executor": "nobody",
      "evidence": [
        "../simplememo-ios/docs/reports/APPLE_ADS_AUTOMATION_2026-08-17.md"
      ],
      "note": "調査レポートのみ。資格情報も無い",
      "blocker": "policy_boundary",
      "unblocked_by": "自社分析が『この予算規模では日次自動入札がノイズ最適化になる』と結論済み。着手しないと決めた側",
      "authority": {
        "domain": "広告出稿・広告予算の変更",
        "human_only": "すべて"
      }
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "広告パフォーマンスの監視と自動調整",
      "executor": "intentional_no",
      "evidence": [
        "../simplememo-ios/docs/reports/APPLE_ADS_AUTOMATION_2026-08-17.md"
      ],
      "note": "自社分析が『この予算規模ではやるべきでない』と結論"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "対照群による増分効果測定",
      "executor": "nobody",
      "evidence": [],
      "note": "未実施",
      "blocker": "statistical_power",
      "unblocked_by": "App Storeのクリックが2.1件/日。分割すると両群とも検出力が出ない"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "紹介・レビュー促進・休眠復帰",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/lifecycle.ts",
        "../simplememo-api/src/nudge.ts"
      ],
      "note": "cronで自動送信"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "コンテンツDecayの検出とRefresh Queue",
      "executor": "ai_executes_gated",
      "evidence": [
        "growth/scripts/analyze.mjs",
        "growth/scripts/build-queues.mjs",
        "growth/content/refresh-queue.json",
        ".github/workflows/seo-check.yml"
      ],
      "note": "**2026-08-25、検出と待ち行列がつながった。**検出は前からあった（analyze.mjs --only decay / unanswered。ノイズフロアつき、窓が93%重なるときは比較を差し控える）が、**出力を待ち行列へ落とす経路が無く**、refresh-queue.json は 2026-08-09 に手で作られたまま更新されていなかった。build-queues.mjs が再生成する。**核心は落とした判断を復活させないこと** —— dropped/done は key で引き継いで戻さず、観測から消えた行も削除せず stale にする（直ったのか窓から外れたのか区別できないため）。**さらに experiments.json で abandoned と判定されたページへは積み直さない** —— 初回試走で実際に踏んだ（未回答クエリの第1位が、到達不能と判定済みのページへ着地していた）。self-test 17件"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "検索意図（Search Intent）の変化検出",
      "executor": "ai_autonomous",
      "evidence": [
        "growth/scripts/search-intent.mjs"
      ],
      "note": "[2026-08-26] growth/scripts/search-intent.mjs が窓をまたいで比べる。**いちばん強い信号は「当たるページが入れ替わったこと」** —— 同じクエリに Google が別のページを当てるようになったなら、検索側の解釈が動いている。実測（08-11 → 08-24）で9件。google keep 系4件が /blog/line-keep-alternatives → /blog/google-keep-shutdown で、順位 13.4 → 5.3。\n\n**出現・消滅は使っていない。**スナップショットは行数上限（1000/900）で切れており、**最小表示回数は両窓とも1**。「消えた533件」は意図の変化ではなく上限で落ちただけ。実測してからこの信号を捨てた。\n\n**窓の長さが違うので表示回数は比べない**（28日 → 13日）。比べるのは順位・CTR・当たるページという長さに依存しない量だけ。"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "施策の停止条件（Marketing stop-loss）",
      "executor": "ai_executes_gated",
      "evidence": [
        "growth/lib/stoploss.mjs",
        "growth/scripts/check-stoploss.mjs",
        "growth/lib/ledger.mjs",
        ".github/workflows/seo-check.yml"
      ],
      "note": "2026-08-25実装。進行中の実験を評価日前に見て、**戻す判断だけ**を出す（expand は返さない —— rollout-guard.ts の kill/promote と同じ非対称）。判定は Wilson 95%区間が重ならないこと＋相対20%以上の低下＋表示200以上。**母数不足・基準値なし・スナップショット欠落は hold** で、CIは落とさない（判定できないことは異常ではない）。初回実行で**偽陽性を1件出した** —— 別の指標（brand_search_impressions）を測っている実験を CTR として判定していた。対象抽出を growth/lib/ledger.mjs の measuresPageCtr に集約し、self-test 16件で固定した。**現状の対象は進行中21件のうち7件**（残りは GA4起点・複数ページ集合・別指標）。つまりこの歯止めは**マーケ施策の3分の1にしか掛かっていない** —— GA4起点の施策に同じ歯止めは無い"
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "SEOとASO間のカニバリゼーション判定",
      "executor": "nobody",
      "evidence": [],
      "note": "**サイト内のカニバリゼーション（1クエリ×複数URL）は実装済み**（growth/scripts/analyze.mjs --only cannibalisation。表示数のフロアつき）。**この行が指しているのは自社サイトとApp Storeページの間**で、そちらは未実装。同じクエリに両方が露出したときにどちらが食っているかを見ていない。**サイト内の分と混同しない**ため、行の題を SEOとASO間と明示してある。 [2026-08-26] それまで「別のレポートが要る」と書いて待ちに分類していたが、**そのレポートはカタログに存在しなかった。**待機ではなく探索。",
      "blocker": "external_data",
      "unblocked_by": "**Analytics Reports のカタログ156本に検索語のレポートは無い**（2026-08-26 に ../simplememo-ios/data/asc/status.json の available_reports を全件確認。search / term / query を名前に含むのは Spotlight Query Performance と Visual Intelligence Image Search Usage の2本だけで、どちらもストア検索語ではない）。**待っても降りてこないので「外部データ待ち」ではない。**残る面（Sales and Trends / Apple Search Ads / ASCのWeb UI）を叩いて確かめる",
      "unlock": "asc_search_terms",
      "blocked_on": [
        {
          "dir": "growth/data/appstore",
          "contains": "Search Term"
        }
      ]
    },
    {
      "area": "③ 自律型マーケティング",
      "task": "ストア内漏斗の観測（表示→ダウンロード→利用）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/asc_funnel.rb",
        "../simplememo-ios/scripts/lib/asc_reading.rb",
        "../simplememo-ios/scripts/lib/asc_columns.rb",
        "../simplememo-ios/.github/workflows/asc-analytics.yml"
      ],
      "note": "2026-08-26実装。日次で自動的に走り、人の承認を挟まない。ゲートは**どれも「言い過ぎ」を止める向き**。(1) **Apple の Event 名を先に決めない** —— 表示に当たる名前を当てられなければ率を出さず、観測した名前をそのまま出す（次に当てられるように）。このリポジトリは「上流の仕様を叩く前に書く」を3回繰り返しているので、同じことを別の領域でやり直さない (2) **窓が違うものを割らない** —— 分子（ダウンロード）と分母（ストア表示）は別のレポートから来る。date_range が一致しなければ率を出さない。1日ぶんを28日ぶんで割ると桁が変わる (3) 分母が 20 に届かなければ率を出さない（⑨と同じ下限）。self-test 23件\n\n**2026-08-26 時点で読めているのは利用だけ** —— Sessions 573 / Unique Devices 168 / Total Session Duration 47,223（これは数値列なので以前から合計に入っていた。**入っていたのに誰も読んでいなかった**）。表示・入口・地域は手元の取得結果が内訳を持つ前の版なので no_breakdown。**次の定時取得（毎日20:30 JST）で決まる。**利用の窓は不明（この取り込みは date_range を持たない）ので、**1セッションあたりの秒数を出していない**"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "サイトの本番デプロイ",
      "executor": "ai_executes_gated",
      "evidence": [
        ".github/workflows/auto-merge.yml"
      ],
      "note": "mainマージ＝Cloudflare Pagesが自動デプロイ"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "バージョン・価格・名称の単一情報源化",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/site-constants.json",
        "scripts/sync_constants.js"
      ],
      "note": "CIがドリフトを落とす。App Store側とは繋がっていない"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "ビルドとTestFlight内部配信",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/docs/release-automation.md",
        "../simplememo-ios/.github/workflows/release.yml",
        "../simplememo-ios/scripts/attach_testflight_testers.rb",
        "data/authority-matrix.json"
      ],
      "note": "タグ作成は人。以降はXcode Cloud＋自動アタッチ **[2026-08-25] ここを gated へ上げようとして、上げてはいけないと分かった。**権限表が『タグ v* の作成』を human_only と定めており、上げるにはそれを渡すしかない —— numbers.md が『人間専任19件のうち11件をAIに渡すと境界が消える』と警告しているのと同じ行為。**代わりに、境界を動かさずに塞げる穴（出荷前のCI緑判定）を実装した。** **[2026-08-27] その境界がオーナー判断で外れた。**\n\n**[2026-08-28] 到達可能側から外した（分類の訂正）。**権限表「アプリのビルド・TestFlight内部配信」は human_only に「タグ v* の作成」を置き、ai_may は空。**タグ push を拒む設計（claude.yml に actions: write を与えない）は2026-08-27 のオーナー判断でも外れていない。**\n**害は件数ではなく向きに出る** —— `--plan` が「作れば進む」と言い続け、天井が実際より高く出る。到達可能な件数は減るが、**下がった天井のほうが本物。**\n\n**[2026-09-03] 境界が外れた。**旧 note は「タグ push を拒む設計（claude.yml に actions: write を与えない）は 2026-08-27 のオーナー判断でも外れていない」と書いていたが、**塞げていたのは1経路だけだった** —— MCP の `actions_run_trigger` は actions:write を持ち（2026-08-28 実測）、issue コメントの橋はセッションをオーナーとして通す（run 30699556723 で実際に出荷済み）。**技術的な経路は開いていて、塞いでいたのは書いてある規則。**\n\nオーナーが渡したのは **submit_review=false の範囲だけ** —— TestFlight 内部配信まで。App Review 提出を伴う起動は権限表で human_only のまま、提出そのものは別領域の門が見る。\n\n**blocker を policy_boundary から verification_pending へ動かした。**作るものは無く、残っているのは1周動いたのを見ること。**executor は動かさない** —— この経路で AI はまだ1回も起動していない。\n\n2026-09-06: オーナーが委譲済みのsubmit_review=falseでAIがrelease.ymlを起動。https://github.com/simplememofast/simplememo-ios/actions/runs/34014697843 がpreflight/タグ検証/内部配信の確認まで成功。v5.8.20の既存VALIDビルド956が内部配信済みだったため冪等に再利用した。今回新規アーカイブを作った実績ではない。App Review提出ジョブはスキップ。変更したのは実行者の確認で、公開の人間承認境界は維持。",
      "authority": {
        "domain": "アプリのビルド・TestFlight内部配信",
        "ai_may": "**submit_review=false に限った release.yml の起動**（v* タグ作成 → Xcode Cloud → TestFlight 内部配信まで）"
      },
      "since": "2026-09"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "申請項目・リリースノート・サブタイトルの投入",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/prepare_app_store_version.rb"
      ],
      "note": "Apple商標スキャン込み。5.2.5リジェクトの恒久対策"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "App Review への提出",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/.github/workflows/submit-review.yml",
        "docs/app-review-execution-2026-09-08.md",
        "docs/delegated-review-gate-20260911.md",
        "data/delegated-review-acceptance-20260912.json",
        "data/release-gate.json"
      ],
      "note": "submit-v* タグ作成は人。Hard Ruleで実機確認が先\n\n**[2026-08-28] 2つの台帳が食い違っていたので更新した（訂正ではない）。**この行の unblocked_by は境界がまだ在る前提で書かれていたが、**同じ日にオーナーが名指しで渡し、権限表は既に `requires_approval: false` ＋ machine_gate。**門は #708 で実装済み（`scripts/check-release-gate.mjs`）。\n\n**executor は動かさない。**`policy.enabled` は false で、**実行側（ASCへの提出・公開の呼び出し）がまだ無い。**「門を作った」を「動いた」と数えないための据え置きで、レビュー返信の行が実際に投稿するまで動かなかったのと同じ基準。\n\n**[2026-09-03 訂正] 「実行側（ASCへの提出・公開の呼び出し）がまだ無い」は不正確だった。**ASC を呼ぶ経路は在る —— review-submit.yml が prepare_app_store_version.rb と fastlane submit_review を回しており、この経路で実際に何度も出荷している。**無かったのは実行側ではなく、門とその経路の接続**（材料の受け渡しと、release.yml から門を呼ぶ配線）。\n\n**executor は据え置く。**同日、門を release.yml の submit_review=true 経路へ配線し、材料は実行側が集める形にした（release-gate-run.mjs --materials）。ただし **policy.enabled は false のままで、まだ1回も通していない。**「配線した」を「動いた」と数えない。\n\n[2026-09-08 実行証拠] オーナーが5.8.46と画像を明示して提出を依頼し、Codexがsubmit-review.yml run34166798798を起動。build1179・日英各3枚の画像を検証して提出し、ASCのWAITING_FOR_REVIEWを確認した。迅速審査も受付済み。ただし既存定義のai_executes_gatedは人の個別承認不要が条件で、今回は個別承認経路。evaluateSubmissionの通過や全リリースQA完了ではないため、AI実行率は加点しない。human_onlyはこの台帳の保守的な据え置きであり、今回の提出操作を人が行ったという意味ではない。詳細は実行証拠文書。\n\n[2026-09-11 自律提出の実行結果] iOS PR479で提出項目を含めて審査枠を判定し、PR480でrelease-blocker Issueの読取権限を補った。run34593711850は強制ゲート通過後に検証済みbuild1342を選択したが、既存の購読関連審査2件でAppleが最終提出を拒否した。PR481で同時審査上限の事前検査と同版の未提出下書き復旧を追加。未受付のためexecutor・分子は維持する。詳細は実行記録。\n\n[2026-09-12 受付確認] 恒常委任によるrelease.yml run34647987301で最新材料・固定SHA・強制提出ゲートを再確認し、既存5.8.54/1342を提出。Apple APIを独立再取得し、submittedDate=2026-09-11T21:13:08.228Z、同じappStoreVersionIDとbuildID、WAITING_FOR_REVIEWを確認した。初めて実際に門を通った受付としてai_executes_gatedへ移し、AI実行率158/179（88.268156%）へ1件加点。過去の未受付試行、公開、無料4回目の実機確認には加点しない。",
      "authority": {
        "domain": "App Review への提出",
        "ai_may": "**ゲートを通った提出の実行**（CI緑・実機確認の記録あり・TestFlightで24時間以上・1日1回）"
      },
      "since": "2026-09"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "実機での事前確認",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/physical-device-verification-20260911.json",
        "docs/physical-device-evidence-20260910.md",
        "../simplememo-ios/data/appstore/device-verification.json",
        "../simplememo-ios/docs/reports/TESTFLIGHT_VERIFY_v5.8.54.md"
      ],
      "note": "Hard Rule。技術的強制ではなく人間のルール\n\n[2026-09-10追記] ユーザーは接続・信頼済みiPhone 13とApple Watchの実機利用を指示し、Developerモード・UIオートメーションを有効にして続行を依頼した。Codexによる同じ配布版の操作・結果観測を委任範囲へ反映する。旧「実機確認は機械には代われない」はこの経路に適用しない。本人の認証・ロック解除は人の前提として残す。現在5.8.54(1342)は同じ配布版で5/6項目を確認済み。購入・復元は未完了で、旧ビルドの購入結果は引き継がない。既存Premium状態からの反復復元は停止し、専用Sandboxで購入前の状態と有効な権利の再取得を別々に検証する準備を進める。全6項目、実行者・日時・同一SHAの証拠が揃うまで実機確認完了の登録・加点はしない。既存の提出・配布ゲートは保持する。詳細はdocs/physical-device-evidence-20260910.md。\n\n2026-09-11: 同じTestFlight 5.8.54（1342、a1cb757）の実機6/6完了。新規購入の既存証拠に、実際の無料状態から元の購入アカウントへ戻した後の独立した自動権利再取得を追加。追加購入0・明示的復元0。項目別証拠と元の下書きを照合し、独立レビューで承認。App Review提出は別ゲート。",
      "unlock": "delegated_device_verification",
      "authority": {
        "domain": "アプリのビルド・TestFlight内部配信",
        "ai_may": "ユーザーが利用を指示し接続・信頼した端末で、同じ配布版の実機テストを操作し、項目別の実結果を記録する"
      },
      "since": "2026-09",
      "measured_at": "2026-09-11"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "App Store への公開（審査通過後）",
      "executor": "human_only",
      "evidence": [
        "../simplememo-ios/fastlane/Fastfile",
        "docs/delegated-review-gate-20260911.md",
        "data/delegated-review-acceptance-20260912.json",
        "docs/quota-physical-publication-20260912.md",
        "docs/gated-publication-execution-20260913.md",
        "docs/app-store-release-5.8.66-observation-20260919.md"
      ],
      "note": "automatic_release がハードコードで false。**[2026-08-27] 「恒久的に手動」はオーナー判断で撤回された。**ハードコードを外すには machine_gate が要る\n\n**[2026-08-28] 2つの台帳が食い違っていたので更新した（訂正ではない）。**この行の unblocked_by は境界がまだ在る前提で書かれていたが、**同じ日にオーナーが名指しで渡し、権限表は既に `requires_approval: false` ＋ machine_gate。**門は #708 で実装済み（`scripts/check-release-gate.mjs`）。\n\n**executor は動かさない。**`policy.enabled` は false で、**実行側（ASCへの提出・公開の呼び出し）がまだ無い。**「門を作った」を「動いた」と数えないための据え置きで、レビュー返信の行が実際に投稿するまで動かなかったのと同じ基準。\n\n**[2026-09-03 訂正] この欄の先頭「automatic_release がハードコードで false」は失効した。**同日 #313 で true になり、prepare_app_store_version.rb は releaseType を AFTER_APPROVAL に強制する。**承認された瞬間に出る。**\n\n**executor は動かさない**（AI が実行しているのではなく、Apple が出している）。むしろこの行で起きたのは、**渡した権限に付けた条件が効かなくなったこと**のほう —— release-gate.json の require_phased_release は「一度に全員へ出さないための最後の砦」と書いてあるが、門は enabled: false・材料は隣のリポジトリ・release.yml から一度も呼ばれない。実測でも段階リリースは付いていなかった（review.phased_release: false・2026-09-02 取得）。\n\n**同日、門の外側で塞いだ** —— simplememo-ios の scripts/lib/phased_release.rb が提出前に段階リリースを作り、作れなければ提出を止める。あわせて evaluateSubmission 側にも段階リリースの条件を置いた（**evaluateRelease は AFTER_APPROVAL では構造的に到達しない**ため、あちらに置いたままでは効かない）。\n\n[2026-09-13 公開経路の実装・反映] iOS PR500の最終CI成功後にmainへマージし、委任公開を有効化。API PR314で公開直前の停止証拠を読めるようにした。5.8.56はASC審査版の不一致で停止。既存5.8.54は対象版観測の非公開保存・読戻しまで成功したが、公開処理は実機記録のASC版ID不足で停止。Appleへの変更要求と公開予約は0件。健康度を含む公開条件の通過と次の実適用は未確認のためexecutorを維持する。\n\n[2026-09-19 5.8.66/1671 一般公開の独立確認] App Store Connect の GET-only 状態確認 run 35387187929 で 5.8.66 / build 1671 が READY_FOR_DISTRIBUTION、review submission 1130af2f-aba2-465b-9c1d-6ed073be73cf が COMPLETE になったことを確認。公開 iTunes lookup でも version=5.8.66 / currentVersionReleaseDate=2026-09-18T19:33:43Z を独立確認した。ただしこの版の提出 run 35359256581 は submit-review.yml の個別承認ラッパーから review-submit.yml を呼び、gated_publication を渡さないため RELEASE_POLICY=after_approval だった。2026-09-13 に定義した委任公開の独立ゲート（MANUAL→健康度・承認6h・kill7d等→asc-publish-version）を通っていない。したがって公開済みという事後事実を事前ゲート通過へ読み替えず、今回もexecutor・AI実行率は変更しない。次の加点は、standing delegation の gated_publication 経路で正当な次期版が公開要求受付→公開readbackまで完走した場合に限る。",
      "blocker": "verification_pending",
      "unlock": "ship_execute",
      "unblocked_by": "5.8.54/1342のASC READY_FOR_SALE・段階公開ACTIVEと一般公開ページの現行版を2026-09-12に確認。公開操作業務のクラッシュ率・kill等の独立条件の充足は未確認。公開の事後観測を事前ゲート判定へ読み替えず、human_onlyを維持する。再提出・新しいTestFlightは不要。 2026-09-13: 委任公開の独立ゲート接続はmain反映済み。次の正当な公開では対象版と一致する実機記録・ASC版/ビルドID、同一確定週の健康度、6時間の承認待機・7日のkill待機等を満たし、要求と公開状態を照合する。過去の自動公開や今回の読取りだけでは加点しない。",
      "authority": {
        "domain": "App Store への公開（審査通過後）",
        "ai_may": "**ゲートを通った公開の実行**（段階リリース限定・1日1回・クラッシュ率とkillの確認つき）"
      }
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "証明書・APIキー・Provisioning Profile の期限監視",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/credential-expiry.json",
        "scripts/check-expiry.mjs",
        ".github/workflows/seo-check.yml"
      ],
      "note": "2026-08-22実装。CIが毎PRで検査し30日前に警告・7日前で落とす。TLSは実測するが、発行元が信用集合に無ければ**期限を報告しない**（中間者復号の環境でプロキシの証明書を本番の期限として書かないため）。**critical 3件（証明書・Profile・ドメイン）の期限日はまだ未把握** — 人が調べて埋めるまで、その3件は監視できていない"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "段階公開への自動昇格",
      "executor": "ai_proposes",
      "evidence": [
        "../simplememo-api/src/rollout-guard.ts",
        "../simplememo-api/test/rollout-guard.test.ts",
        "scripts/check-rollout-promotion.mjs",
        "data/rollout-promotion.json",
        "data/authority-matrix.json"
      ],
      "note": "**意図的に提案止まり。**露出を広げる方向は不可逆（広げてから戻しても見た人が見なかったことにはならない）なので人が承認する。/admin/rollout-guard に積まれる。v5.8.1（2026-08-22）でクライアント側が本番に載り、**昇格の判断が実際に発生しうる状態になった**（それまでは判断の対象が無かった）\n\n**[2026-08-26] 判断は実際に発生している。**`tf04_progress` が 5% で稼働中で、ガードは毎時判定を出している（decisions 30件）。ただし現在の判定は hold で、理由はサンプル不足（露出 5〜12 / 判定に要る 30 に未達）。**昇格の提案はまだ1件も積まれていない**（awaiting_approval 0）\n\n**[2026-08-27] 機械ゲートを作った。executor は動かさない。**オーナー判断で境界が外れたが、権限表は不可逆な領域の承認を外すのに machine_gate を要求するので、宣言ではなく実装で外した（`scripts/check-rollout-promotion.mjs` の `evaluatePromotion` / `data/rollout-promotion.json`）。落とすもの: ガードの判定が promote でない／判定が120分より古い／3指標のどれかが各群30の母数に届かない／梯子を飛ばす／50% を超える（**100% への最終段は人**）／48時間寝ていない／直近7日に kill／日次上限1／`drill_`／killed。**材料が欠けたら必ず hold**（13欄を1つずつ落として確かめた）。\n\n**この門は今日のボタンを押せない。設計どおり。**ガードは rollout 5% では判定に届かず、自分で『露出30には rollout 19% 以上』と計算している（run 33076125334）。**判定に届かない露出から踏み出す最初の一歩は証拠で正当化できない**ので、そこは人が押す。門が効くのは25%以降。\n\n**executor は `ai_proposes` のまま動かさない。**残っているのは (1) 実行側（simplememo-api が `--plan` を読んでフラグを設定する経路）と (2) オーナーが `auto_promote.enabled` を立てること。**「門ができた」を「昇格した」と数えない** —— レビュー返信の行が実際に投稿するまで動かなかったのと同じ基準\n\n**[2026-08-28] 入口を `impl_machine_gate`（実装）から `rollout_first_pass`（待ち）へ移した。作るものもオーナー操作も残っていない。**門は 2026-08-27 に入り（`evaluatePromotion`）、カナリアは 2026-08-27 に 25% へ上がり、`auto_promote.enabled` は 2026-08-28 にオーナーが立てた。**残っているのは 48時間の寝かせ（2026-08-29 まで必ず hold）と、3指標が各群30以上で判定できること**で、どちらも実装では早められない。`refund_observe` を implement から wait へ移したのと同じ形の訂正。",
      "blocker": "verification_pending",
      "unlock": "rollout_first_pass",
      "unblocked_by": "**[2026-08-28] ここに残件として書いてあった2つは、どちらも済んだ。**(1) 実行側の経路 … simplememo-api#190「段階公開の昇格を実行する側」。(2) `auto_promote.enabled` … `data/authority-matrix.json` に 2026-08-28 の記録があり、オーナーが名指しで委譲したのでAIが立てた。読み取り専用の実機確認（simplememo-api run 33132559234・`apply: false`）で門は `hold / 自動昇格が有効になっていない` を返しており、**止めていたのはこのフラグだけだった。**\n\n**したがって `not_started` は事実として誤り。**残っているのは実装でもオーナー操作でもなく、**門が実際に1件通ること**。hold の理由は実検査側（48時間の寝かせ・各群30の母数・梯子・上限50%・日次1段）へ移っている。ガードは rollout 5% では判定に届かず（露出30には rollout 19% 以上が要る）、**判定に届かない露出から踏み出す最初の一歩は人が押す**ので、そこは human_only のまま",
      "authority": {
        "domain": "段階公開の拡大（rollout の引き上げ）",
        "ai_may": "**ゲートを通った昇格の実行**（ガードが判定を出せた段のみ・上限 50% まで・1日1段）"
      }
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "Crash-free率・送信成功率による自動停止",
      "executor": "ai_autonomous",
      "evidence": [
        "../simplememo-api/src/rollout-guard.ts",
        "../simplememo-api/test/rollout-guard.test.ts",
        "data/stop-drills.json"
      ],
      "note": "起動完走率（launch_incomplete の裏返し＝クラッシュ代理指標）・送信成功率・エディタ→送信到達率の3本で判定。1指標でも割れたら止める。**2026-08-22実装。本番でまだ1回も発火していない**（段階公開中のフラグがゼロのため）。実装した≠動いた。同日 v5.8.1 でクライアント側の段階公開が本番に載ったので、**フラグを一つ段階公開に載せた時点で初めて発火しうる状態になる**。それまではガードが見る対象そのものが存在しない\n\n**[2026-08-26 訂正] 「段階公開中のフラグがゼロ」は事実と違っていた。**`tf04_progress` が本番で稼働している —— 08-22 に 0% で定義、08-23 に 1%、08-25 に **5%**（引き上げの description に「1% では露出3で判定に届かなかったため」と書いてある）。ガードも走っている: last_run_at 2026-08-26T04:00:01Z / decisions 30件 / promotion_frozen false。**発火しない本当の理由はサンプル不足** —— 3指標とも judged: false で、「サンプル不足（露出 12 / 対照 236 < 30）。**判定していない（異常なしではない）**」を返している。**待てば解けるものではない**（露出を上げるのは authority-matrix domain 16 で承認要）。この欄が 08-22 の記述のまま4日間止まっていたのは、**実物を叩かずに台帳の散文を引き継いだから**（data/operating-memory.json om-2026-08-26-ledger-outran-reality）\n\n**[2026-08-26] 群の作り方に fail-open の欠陥。**splitByBucket がinstall_id のハッシュだけで割っていて、版を見ていなかった。5.8.1 未満の install は機能を受け取っていないのに、bucket 次第で露出群に入る —— **差が消える＝止めない方向にだけ歪む。**版で絞る修正を実装済み（未マージ・本番未反映）。**この行を ai_autonomous と数えているのは『指標が割れたら止めること』についてであって、『正しい群で測れていること』についてではない**"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "Remote Feature Flag と緊急Kill Switch",
      "executor": "human_only",
      "evidence": [
        "../simplememo-api/src/flags.ts",
        "../simplememo-api/src/config.ts",
        "../simplememo-ios/SimpleMemo/FeatureFlagRollout.swift",
        "../simplememo-ios/SimpleMemoTests/FeatureFlagRolloutTests.swift",
        "../simplememo-ios/docs/feature-flag-client-spec.md",
        "../simplememo-ios/release_notes/ja-JP/5.8.1.txt",
        "../simplememo-api/data/rollout-bucket-vectors.json",
        "../simplememo-api/test/rollout-vectors.test.ts",
        "../simplememo-ios/scripts/qa/check_rollout_vectors.py",
        "data/stop-drills.json",
        "docs/gated-publication-execution-20260913.md"
      ],
      "note": "[2026-08-22訂正] 前回の「iOS側が入るまで実際には止められない」は誤り — v4.7から /v1/config + REMOTE_FLAGS_JSON で全体キルができていた。同日、不足分（段階公開・キャッシュ期限・取得経路のテスト）を実装し、**2026-08-22 に v5.8.1 として本番リリースした**（リリースノートも「問題があれば即座に取り下げられる仕組み」と書いている）。これで台帳上の『両側が揃った』が、実際に利用者の端末に載った状態になった。**human_only なのは kill を叩くのが人間だから** — AIが自動で kill する経路は無い。さらに**本番で kill を1回も通していない**（止まることを確かめていない停止機構は無いのと同じ）。v5.8.1 で経路が本番に載ったので、**次に確かめるべきはこれ**。**バケット割りは iOS ↔ relay の契約として固定した**（同日） — 期待値15本は元々サーバ実装を一度回して Swift にコピーしたもので、**凍っているのは Swift の期待値のほう**（サーバが変わっても Swift のテストは通り続ける）。本番に載った以降ここがずれると『サーバでは配布対象だがアプリでは対象外』になり、**出荷済みのバイナリは直せない**。両側が同じ1ファイルを読む形にした\n\n**[2026-08-26 訂正] 「本番で kill を1回も通していない」は事実と違っていた。**/admin/flags の history に残っている: 2026-08-22 14:44:53Z に `tf04_progress` を rollout 100 で作成（description「TestFlight で kill の実証を行うための一時配布」）→ 14:57:38Z に **killed: true**（actor: human）→ 15:00:12Z に解除 → 15:01:10Z に rollout 0 へ戻し description を「**kill の実証完了（2026-08-22）**」へ。**この欄を書いた日と同じ日に、実証は済んでいた。**ただし残っているのはサーバ側の状態遷移だけで、**端末で実際にオフになったことの記録は無い**（data/stop-drills.json の flag-kill）\n\n**[2026-08-28] 到達可能側から外した（分類の訂正）。**権限表「段階公開の撤回（カナリアガード）」が human_only に「ガードの判定によらない kill の実行」を置いている。**緊急停止はその定義そのもの**（ガードの判定によらない）なので、人の側に残る。\n**害は件数ではなく向きに出る** —— `--plan` が「作れば進む」と言い続け、天井が実際より高く出る。到達可能な件数は減るが、**下がった天井のほうが本物。**\n\n[2026-09-13 準備の実機確認] 最新の包括委任に基づく限定停止・復元の計画を作成し独立レビュー済み。iPhone 13の5.8.56/1428で、再取得の試行時刻だけを除いた通常起動が実サーバー設定を取得することを確認し、連携・宛先・下書き設定の不変を照合した。画面の対象行をまだ観測できず、本番の定義・kill・復元は0件。既存tf04_progress停止は維持し、executorと加点は変えない。準備成功を遠隔停止の成功へ読み替えない。\n\n[2026-09-19 実機準備の前進] 5.8.67/1686のiPhone 13で、独立したUI検査によりObsidian連携の一時OFF、対象の案内行の表示、同じUIでのON復元、空の編集画面への復帰を確認した。別実行と通常再起動後を含む3検査は成功し、宛先などの非runtime設定・履歴・送信待ちデータは不変だった。再取得の試行時刻だけを1回の起動引数で0にし、実サーバー設定の取得成功時刻の更新と、引数なし再起動後の通常キャッシュ維持を確認した。フラグ値の注入・本番変更・追加配信は0件。元のTestFlight導入来歴と、本番killによる表示変化・所有する定義の復元は未検証である。実killは公開の7日間待機を再開するため、既存の公開準備を優先して保留する。表示経路の解消を遠隔停止の成功や実機QA全体の合格へ読み替えず、executor・正式加点は据え置く。",
      "blocker": "policy_boundary",
      "unblocked_by": "緊急停止は人が握る",
      "authority": {
        "domain": "段階公開の撤回（カナリアガード）",
        "human_only": "ガードの判定によらない kill の実行（手動・訓練を含む）"
      }
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "審査項目・商標・プライバシー表示の整合確認",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/lib/app_metadata.rb",
        "../simplememo-ios/.github/workflows/qa-static.yml"
      ],
      "note": "2026-08-22に検査を拡張。名前・サブタイトル（5.2.5・商標）に加え、キーワード欄とリリースノート（長さ上限・3.1.2の語）も毎PRで見る。自己テスト20件追加。**キーワードの実値はまだASC内にあり移していない**ので、その分は NOTE として毎回出る"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "AI・外部サービス停止時の独立した緊急停止経路",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/emergency-stop.json",
        "scripts/check-emergency-stop.mjs",
        "scripts/autopilot-gate.mjs",
        ".github/workflows/obsidian-autopilot.yml"
      ],
      "note": "2026-08-22実装。**主系と副系を同時に、意図が残る形で止める唯一のスイッチ。**予算ゲートは主系しか止めず、秘密鍵の削除は「静かに寝る」ので止めたのか壊れたのか区別がつかなかった。他のどの判定よりも先に効き、force でも飛び越えられない。**AIは止められるが解除できない**（非対称）。CIは台帳ではなく**配線**を見る（判定・ワークフロー・Runbookの3経路）",
      "since": "2026-08"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "ChatOps によるリリース起動",
      "executor": "ai_executes_gated",
      "evidence": [
        "docs/chatops-execution-20260908.md",
        "../simplememo-ios/.github/workflows/release-command.yml",
        "../simplememo-ios/scripts/release_command.rb",
        "../simplememo-ios/scripts/lib/testflight_receipt.rb"
      ],
      "note": "issue コメントで起動。コメントするのはオーナー\n\n**[2026-08-28] 到達可能側から外した（分類の訂正）。**起動コメントを打つのがオーナー、という設計そのものが人間ゲート。**打つ主体を機械にすると、ゲートが消えて何も残らない。**\n**害は件数ではなく向きに出る** —— `--plan` が「作れば進む」と言い続け、天井が実際より高く出る。到達可能な件数は減るが、**下がった天井のほうが本物。**\n\n2026-09-08実行検証: オーナーの継続的な実行権限委譲に基づき、Codexがissue35へ5.8.52 TESTFLIGHTを一度投稿（comment5578707772）。run34183973142はparse・対象CI・AppScope・固定タグ・Cloud・配布の全工程を成功。対象ソース4d87e9d10b5a0f90f6fba567bb84aa16cddda926、ビルド1275、Apple側の所属GETを伴う配布証明を回収し独立再確認した。旧版固定はPR434で解消済み。作者名だけを安全条件とせず、版・ソース・CI・対象アプリ・Cloud成功・グループ所属の機械検査を維持するためai_executes_gatedへ移す。TestFlight配布の起動実績であり、実機QAやApp Review提出・公開の完了には加点しない。",
      "authority": {
        "domain": "アプリのビルド・TestFlight内部配信",
        "ai_may": "**submit_review=false に限った release.yml の起動**（v* タグ作成 → Xcode Cloud → TestFlight 内部配信まで）"
      },
      "since": "2026-09"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "実費の記録（月次台帳）",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/autopilot-cost.json",
        "scripts/autopilot-budget.mjs"
      ],
      "note": "2026-08-22実装"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "実費の抽出（実行ログから）",
      "executor": "ai_executes_gated",
      "evidence": [
        ".github/workflows/obsidian-autopilot.yml"
      ],
      "note": "total_cost_usd を抽出しサマリと通知へ"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "上限超過での自己停止",
      "executor": "ai_executes_gated",
      "evidence": [
        ".github/workflows/obsidian-autopilot.yml",
        "scripts/autopilot-budget.mjs",
        "scripts/autopilot-gate.mjs"
      ],
      "note": "予算ゲートが主系runを止める。副系は止められない。**【2026-08-25】上限は2種類あり、長く効いていたのは月次だけだった。**model-routing.json の `max_usd_per_run`（1回あたり）は宣言だけで実行時に見る経路が無く、08-23の1回は article の上限 $2.00 に対し $7.2967（3.6倍）を使い切って正常終了している。`--check-run-cap` を route ステップに配線して塞いだ。費用はrunが終わるまで確定しないので**止められるのは次の1回**。種別ごとに見るので記事の超過が修理を止めることはなく、止まるのは主系だけなのでレビュー待ちの間も副系が出荷を続ける。解除は人間のみ（`--ack-overrun`）。**本番でまだ一度も発火していない。**"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "月次上限の決定",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/spend-approvals.json",
        "scripts/monthly-budget.mjs",
        "scripts/lib/monthly-budget-decision.mjs",
        "data/autopilot-cost.json",
        "docs/monthly-budget-decision-2026-09-07.md"
      ],
      "note": "2026-09-07: オーナーの包括承認を受け、AIが主系9回$67.0402の実績から月次総額$280の維持と種別配分を決定し、monthly-budget --applyで実行予算へ反映した（spend-approvals seq=3）。記事$180→$125、修理$60→$115、その他予備枠$40を維持。過去のhuman承認は保持し今回のapproved_byはai。実際のruntime budget CLIで記事$20/回・修理$18/回と新しい種別残枠を確認。観測欠落、配分逸脱、変更幅・変更間隔違反をCIで拒否する。部分月・主系のみの判断で、CCR実費、全社予算、最適配分の実証には流用しない。",
      "authority": {
        "domain": "AI実費（開発・運用のトークン費）",
        "ai_may": "オーナーの包括委任に基づく、実績を根拠とした月次上限・種別配分の決定と実行予算への適用"
      },
      "since": "2026-09"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "1記事あたり単価の算出",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/autopilot-budget.mjs"
      ],
      "note": "usd_per_shipped。課金者あたりは無い"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "タスク単位の予算",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/autopilot-cost.json",
        "scripts/autopilot-budget.mjs",
        ".github/workflows/obsidian-autopilot.yml"
      ],
      "note": "2026-08-22実装。article/repair/analysis/pr/qa_triage の5種別に月次枠。**合計が月次上限を超えるとCIが落ちる**（超えたら枠は装飾）。種別の枠切れでは主系全体を止めない — 記事の枠切れが修理まで巻き込むため。**枠も暫定**（月次上限が placeholder なので、そこから割った枠も placeholder）",
      "since": "2026-08"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "モデル別・再試行別の内訳",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/autopilot-cost.json",
        "scripts/autopilot-budget.mjs"
      ],
      "note": "2026-08-22実装。実行ログの modelUsage から記録。**費用の按分はログに無いので回数しか言えない**"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "品質・速度・価格に応じたモデルルーター",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/model-routing.json",
        "scripts/check-model-routing.mjs",
        ".github/workflows/obsidian-autopilot.yml"
      ],
      "note": "2026-08-22実装。種別→モデルを台帳化し、ワークフローが --resolve で引く。**引かれない表は装飾**なので、ワークフローが実際に呼んでいることをCIが見る。**不可逆なタスク（対外配信）を最安ティアに落とすことを禁止**（節約額より失う額が大きい）",
      "since": "2026-08"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "小型→大型→人間への段階的移管",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/model-routing.json",
        "scripts/check-model-routing.mjs",
        ".github/workflows/obsidian-autopilot.yml",
        "../simplememo-ios/scripts/qa/ai_triage.sh"
      ],
      "note": "2026-08-22実装。種別ごとに小型→大型→人間のはしごを台帳で持ち、`--escalate <種別> --attempt N` が次の段を返す（人間に達すると exit 3）。**すべてのはしごが human で終わること**と、1段目が rules[種別].model と一致することを検査する（不一致を実際に1件検出して直した）。主系ワークフローは --resolve の結果でモデルを選ぶので、台帳が実行に効いている。残る弱さ: attempt を数えて自動で上げる呼び出し元がまだセッション側にしかない",
      "since": "2026-08"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "Prompt Cache・結果キャッシュ",
      "executor": "intentional_no",
      "evidence": [],
      "note": "**やらないと決めた。**Prompt Cache は毎朝のプロンプトが静的でAPI側のキャッシュが効く範囲にあり、こちらで持つと二重管理になる。結果キャッシュで重いのは内部リンクの200検証（13,273件）だが、これはCIの話でセッションのトークンではない — **節約したい対象が違う**"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "コンテキスト圧縮（毎朝の1枚）",
      "executor": "ai_executes_gated",
      "since": "2026-08",
      "evidence": [
        "scripts/daily-brief.mjs",
        "data/emergency-stop.json",
        "data/autopilot-runs.json"
      ],
      "note": "2026-08-22実装。毎朝のセッションは着手前に Runbook・status・運転台帳・実費台帳・自己修復の判定・緊急停止・移管規則を**それぞれ読んでいた。**同じことを毎日6ファイル分のトークンで再構成していたので、1枚にまとめた。**新しい情報を作らない** — 既存の集計関数を呼ぶだけで、数字は台帳が正。未修理の故障も自己修復の判定をそのまま使う（数え直すとレーンFと表示がずれる）"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "無限ループ・重複実行の防止",
      "executor": "ai_executes_gated",
      "evidence": [
        "docs/obsidian/AUTOPILOT_RUNBOOK.md",
        "scripts/autopilot-gate.mjs"
      ],
      "note": "--max-turns 250・当日ブランチ占有・冪等性チェック"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "異常消費の検知",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/autopilot-budget.mjs",
        "data/autopilot-cost.json"
      ],
      "note": "2026-08-22実装。絶対額ではなく直近中央値との比。実績5件未満では『判定していない』と言う"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "モデル障害・レート制限時のフォールバック",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/model-routing.json",
        "scripts/check-model-routing.mjs",
        "scripts/autopilot-gate.mjs",
        "data/escalation-rules.json",
        "../simplememo-ios/scripts/qa/ai_triage.sh"
      ],
      "note": "2026-08-22実装。縮退先を台帳に持ち、実行判定が DEGRADE_MODEL / FAIL_NO_MODEL を返す（使えるモデルが尽きたら走らない — 静かに寝ない）。両コードに移管規則がある。**不可逆な種別に最安のモデルを割り当てると落ちる。**残る弱さ: 使えないモデルを検知して渡す経路が無いので、縮退の起点は今も人かセッションの観測",
      "since": "2026-08"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "新モデル導入前の固定評価セット",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/model-eval-set.json",
        "scripts/check-model-eval.mjs",
        "data/model-routing.json"
      ],
      "note": "2026-08-22実装。失敗分類の6ケースを固定し、合格ライン83%＋**「分からない」と答えられること2件を必須通過**にした。合格条件は決定論（ラベルの照合のみ）— AIにAIを採点させると採点側を替えた時点で履歴が無効になるため。**評価はまだ一度も走らせていない**ので policy.enforce は false（true にすると現行3モデルが未評価で落ちる）",
      "since": "2026-08"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "副系CCRの実費観測",
      "executor": "nobody",
      "evidence": [
        "data/autopilot-cost.json"
      ],
      "note": "スケジュール起動セッションのログが外部から読めない。構造的に不可",
      "blocker": "structural",
      "unblocked_by": "スケジュール起動セッションのログが外部から読めない。セッション自身も自分のトークン費を知らない"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "採用された改善1件あたりのAI原価",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/ai-unit-cost.mjs",
        "data/autopilot-cost.json",
        ".github/workflows/seo-check.yml"
      ],
      "note": "**[2026-08-26] 実装した。**以前ここに書いていた「分母が無い」は半分が古かった —— run には既に `outcome`（shipped / no_artifact / failed）があり、却下と計測失敗は分母から外せていた。**残っていたのは revert だけ**で、出荷したあとで戻した変更が採用として数えられていた。`outcome: reverted`（`reverted_why` 必須）を足し、分母から外すようにした。\n\n**分子には失敗した run の費用も残す。**採用1件の原価は、うまくいかなかった試行を含めた額であって、成功分だけを割った額ではない。\n\n**値はまだ名乗れない。**採用2件 < MIN_ADOPTED 10 なので `measured: false` を返す（費用の分散が大きく 0〜11.93 USD、数件の平均は方向すら示さない）。参考値 $10.02 は出力に出るが「未測定」と明示している —— **「まだ測れていない」であって「原価が低い」ではない。**",
      "since": "2026-08"
    },
    {
      "area": "⑤ AI予算・トークン管理",
      "task": "AI費用に対する粗利（AI原価の回収）",
      "executor": "nobody",
      "evidence": [],
      "note": "2026-09-07: 日次の欠測と別に、Appleの暦週・暦月レポートを非公開側で取得済み。取得だけで粗利は未計算。推定受取額と確定入金を区別し、同期間のAI実費・共有プランの配賦・未観測費用を照合する。",
      "blocker": "external_data",
      "unblocked_by": "比較可能な期間の受取額とAI費用・配賦を非公開側で突き合わせて原価回収を評価する。28日の日次観測だけで完了にしない。",
      "unlock": "revenue_28d",
      "blocked_on": [
        {
          "file": "data/revenue-series.json",
          "path": "covered_days",
          "atLeast": 28
        }
      ]
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "ファネル分析（インストール→初回メモ→継続→課金）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/analytics.ts",
        "../simplememo-api/docs/reports/FUNNEL_EVALUATION_2026-08-20.md"
      ],
      "note": "4回連続の定点評価\n\n**[2026-08-26] ストア側の手前が繋がった。**この行が見ているのはアプリ内（インストール以降）で、その手前の「ストアで見られた → ダウンロードされた」はどこも見ていなかった。asc_funnel.rb がそこを読む（③の別行）。**まだ繋いでいない** —— 2つは別の窓・別の分母で、**繋ぐには同じ窓に揃える必要がある**（asc_funnel.rb は窓が違えば率を出さない）"
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "コホート分析（継続率・課金率）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/cohort-report.ts",
        "../simplememo-api/src/analytics.ts",
        "../simplememo-api/src/index.ts",
        "../simplememo-api/test/cohort-report.test.ts",
        "../simplememo-api/docs/reports/RETENTION_MONETIZATION_COHORT_2026-07-29.md"
      ],
      "note": "2026-08-22。**都度レポートから週次の自動実行へ。**計算も、週次サマリの中でそれを呼ぶ経路も既にあり、**無かったのは定期的に回して読む仕組み**だった（人が叩いた日にしか読まれていない）。運用報告なので ENABLED フラグでは止めず、宛先の有無だけで自己ゲートする（autopilot_report / analytics_daily_report と同じ流儀）。この領域は母数が小さいので、**成熟30件未満では変化を解釈しない**し、差が**1人ぶんの幅**に収まるなら「区別できない」と書く（前週の母数が小さければそちらの分解能を使う）。**言うことが無い週は送らない** — 読めるようになった週・言える差が出た週・集計できなかった週の3つだけ。毎週同じ行を送ると読まれなくなる。残る弱さ: **D28 は BQ の28日蓄積待ち**（9/6前後）。実際に「読める」判定が出るのは母数が30件に届いてからで、いまの規模ではしばらく『母数不足』が続く",
      "since": "2026-08"
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "KPI定義と集計SQLのバージョン管理",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/kpi-definitions.json",
        "scripts/check-definitions.mjs",
        ".github/workflows/seo-check.yml",
        "growth/lib/",
        "../simplememo-api/docs/analytics-golden.md",
        "scripts/code-authorship.mjs",
        "data/code-authorship.json"
      ],
      "note": "2026-08-22実装。KPI6件の定義と、**算出元ファイルの sha256** を台帳に持つ。計算コードが変われば version を上げるまでCIが落ちる（`--bump <id> --why` で履歴が残る）。狙いは数字ではなく**定義の凍結** — 「自動化率が上がった」の半分が計算を変えたからだった、を起こさないため。導入直後にRunbookの編集で実際に発火し、履歴に「定義は変えていない」と残した。残る弱さ: 集計SQLはまだ台帳に無い（BigQuery側は analytics-golden.md 止まり） [2026-08-22追記] **原稿の「変更行の98.8%」が再現できなかった**ので、数え方そのものを script にして凍結した（KPI定義7件目）。台帳の算数と、**headline が実測とずれていないこと**をCIが見る — 「数字だけ良くする」経路をつぶすため。窓の切り方1つで 94.2% ↔ 96.6% と 2.4pt 動くので、**計測日を窓に入れない**ことを定義に含めた",
      "since": "2026-08"
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "データ不足時に「何もしない」と判断",
      "executor": "ai_executes_gated",
      "evidence": [
        "docs/obsidian/AUTOPILOT_RUNBOOK.md",
        "scripts/autopilot-gate.mjs",
        "growth/scripts/build-queues.mjs"
      ],
      "note": "ノイズフロア＝期待クリック3未満／28日窓未満でスナップショットを作らない"
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "売上・課金・返金・広告の照合",
      "executor": "ai_autonomous",
      "evidence": [
        "../simplememo-ios/scripts/asc_revenue.rb",
        "../simplememo-ios/data/revenue/series.json",
        "growth/scripts/revenue-series.mjs",
        "data/revenue-series.json",
        "data/financial-policy.json"
      ],
      "note": "2026-08-26 に照合を実装（../simplememo-ios/scripts/asc_revenue.rb、asc-analytics.yml で毎日実行）。**4つの現況を実データで確かめた:** **売上・課金** … App Store Purchases Standard の Purchases / Proceeds / Sales を重ならないスパンで積む（ONGOING レポートは過去日を含めて再送されるので、重なりを足すと二重計上）。**手数料** … 実データ $3.05 / $2.59 から帯 [0.1473, 0.1544] を出し Small Business 15% と同定。セント丸めがあるので1点では比べない。30% へ移ったら（＝制度から外れたら）検知する。**返金** … Apple は負の Purchases / Sales で返す。1件も観測していないが、**範囲合計では課金と相殺されるので「返金が無かった」とは言えない**（言えるのは「返金が課金を上回る範囲は無かった」まで）。**広告** … 0 は実測（未出稿）。Campaign 列は取得側が既に読んでいるので出稿した日に現れる。CAC は広告費ゼロである以上**定義上存在しない** —— 0除算を「CAC 0円」と書かない。**まだできないこと:** レポート間の件数突き合わせ（Purchases 1件 vs Subscription Event 4件）は**窓が違う**（08-23 のみ / 08-22..08-23）うえ、保存している内訳が範囲の合計で日別ではないため構造的に不可能。日別の内訳を取得側に足すのが前提",
      "blocker": null,
      "unblocked_by": null,
      "unlock": null,
      "$prev_note_2026_08_26": "**この行は自分自身と矛盾していた。**note が「4つのうち材料が揃ったのは1つだけ」と書く一方で unblocked_by は「材料は降りた。残るのは実装」と書いていた。2026-08-26 に一次資料（data/asc/2026-08-26 の10レポート）を読んで解消した。**同じ形の食い違いはこの行で2度目**（1度目は「レポートが0件」と「降りた」の同居）"
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "欠損・遅延・重複データの検査",
      "executor": "ai_executes_gated",
      "evidence": [
        "growth/scripts/check-data-quality.mjs",
        "growth/scripts/ingest-gsc.mjs"
      ],
      "note": "2026-08-22実装。**作った直後の初回実行で実データの欠陥を検出した** — 2026-08-09スナップショットの /vs/ticktick/ が2行あり、クリックが二重に乗りうる状態だった（URL正規化で衝突した行を畳んでいなかった）。取り込み側に mergeByKey を入れて恒久対策。重複と内部不整合は落とし、日付の欠けと鮮度は報告のみ",
      "since": "2026-08"
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "CAC・LTV・回収期間・粗利の統合",
      "executor": "ai_proposes",
      "evidence": [
        "growth/scripts/ingest-asc.mjs",
        "data/financial-policy.json"
      ],
      "note": "2026-09-07: 日次・暦週・暦月の購入集計とプラン別Subscription Stateは取得済み。状態在庫は新規解約や一意な契約人数ではない。期間合計から流入別LTV・継続率・回収期間は算出できず、統合判断は未完了。",
      "blocker": "external_data",
      "unblocked_by": "獲得の分母・獲得費用と同一コホートの継続・課金を照合する。広告費0の推測からCACを定義せず、獲得費用の範囲を明示する。日次28日のみでは不足。",
      "unlock": "revenue_28d",
      "blocked_on": [
        {
          "file": "data/revenue-series.json",
          "path": "covered_days",
          "atLeast": 28
        }
      ]
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "季節性・外部要因の分離",
      "executor": "ai_executes_gated",
      "evidence": [
        "growth/scripts/decompose-series.mjs",
        "growth/data/annotations.json",
        ".github/workflows/seo-check.yml"
      ],
      "note": "2026-08-22実装。曜日係数を実測から出し（日1.17 月1.12 火0.97 水0.93 木1.05 金0.83 土0.81）、外れ値を注釈台帳と突き合わせて説明のつかないものを名指しする。**28日未満では判定を拒否する** — 足りない標本で「効いた/効かなかった」を言わせないため。金土は平日比0.8倍まで落ちるので、金曜に出した施策は何もしなくても効かなく見える。残る弱さ: 分離できるのは曜日だけで、季節・外部イベントは注釈頼み",
      "since": "2026-08"
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "対照群に対する増分効果の評価",
      "executor": "nobody",
      "evidence": [],
      "note": "母数が小さく（App Storeクリック2.1件/日）、対照群を割ると両群とも検出力不足",
      "blocker": "statistical_power",
      "unblocked_by": "同上"
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "予算変更幅・損失上限・撤回条件",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/financial-policy.json",
        "scripts/check-financial-policy.mjs",
        "data/authority-matrix.json"
      ],
      "note": "2026-08-22実装。**動かす予算が小さいうちに書いた** — 大きくなってから書くと、そのときの都合に合わせた基準になる。AI実費は稼働中（変更幅25%・間隔14日・損失上限$60・撤回条件3件）、広告は未着手、価格はAI対象外。**損失上限が現在の上限以下だとCIが落ちる**（初日から発火する上限は上限ではない）",
      "since": "2026-08"
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "可逆／不可逆の承認レベル分け",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/authority-matrix.json",
        "scripts/check-authority.mjs"
      ],
      "note": "2026-08-22実装。13領域中9が承認制"
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "月次予算の決定",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/company-monthly-budget.json",
        "data/company-monthly-budget-execution.json",
        "scripts/company-monthly-budget.mjs",
        "scripts/press-release-next.mjs",
        "docs/company-monthly-budget-20260913.md"
      ],
      "note": "2026-09-13: オーナーの明示委任に基づきAIが全社の月次予算を策定。銀行取得残高と帳簿残高、会計取引、支払原本、過去精算を照合し、通常運営計画・過去精算・条件付き不足資金を区別した。9月末までの追加任意支出0円と既存義務保護を決定し、PR1302で支出管理へ適用。本番main版の実在PR候補で全社予算による保留、原本のある既存精算項目で義務維持を実行。公開設定のHTTP200・SHA一致を読戻しした。主系AI280USDの再設定ではなく全社予算の決定・適用1件。銀行やカードの全決済の自動制御、送金、過去精算完了、月次締めは加点対象外。"
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "資金繰りシナリオ（悲観・標準・楽観）",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/financial-policy.json",
        "scripts/check-financial-policy.mjs",
        "data/vendor-register.json"
      ],
      "note": "2026-08-22実装。**出ていく側だけ**（悲観$150／標準$40／楽観$25）。収入はASC未接続で機械が読めないため、**ランウェイ（月数）は出さない** — 手元資金も収入も入っていないので月数を書くと嘘になる。CIが「収入未接続なのに runway_months を書いていないか」を見る",
      "since": "2026-08"
    },
    {
      "area": "⑥ アプリ運営意思決定",
      "task": "結果の5分類（成功／失敗／無変化／判断不能／計測失敗）",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/operating-memory.json",
        "scripts/check-operating-memory.mjs",
        "growth/lib/ledger.mjs",
        "growth/experiments/experiments.json"
      ],
      "note": "2026-08-25実装。**「判断不能」と「計測失敗」を分けるのが要点。**前者は待てば解け、後者は待っても解けない。分ける前は experiments.json の `inconclusive` 7件が**全件が実は計測失敗**（変更前の値を未記録）で、待てば解けるものとして扱われていた。CIは (a) 基準値が無いのに inconclusive と書く (b) 基準値を持たないまま実験を走らせる の両方を落とす"
    },
    {
      "area": "⑦ 法人経営",
      "task": "銀行・カード残高の読み取り（日次）",
      "executor": "ai_autonomous",
      "evidence": [
        "../simplememo-api/src/freee.ts",
        "../simplememo-api/test/freee.test.ts",
        "../simplememo-api/docs/freee-setup.md"
      ],
      "note": "**2026-08-27 10:00 JST、cron `freee_balance` が本番で初めて走った**（`0 1 * * *`・eligible=3 sent=2 errors=0・reason `days_left=90 complete=true counted=2 unreadable=0`）。同日、freee の画面と突き合わせて **cash_jpy 638,593 / card_jpy -1,600,509 が完全一致**することを人が確認した。カードは負債なので手元資金に足さず別枠にしてある。**書き込み経路は無い**（テストがモジュールに書き込み系の関数名が無いことを固定している）。**2026-08-27、鮮度も機械が言えるようになった。**一覧APIに `with_last_synced_at` / `with_sync_status` を渡すと `last_synced_at` / `sync_status` が返る（freee が2024-11-05に追加）。渡していなかったので7フィールドしか返っていなかった、というのが真相。本番の実測値は口座ごとに3種類に割れた —— GMOあおぞら（API連携）は `success` で `2026-08-26T23:54:28+0900`、楽天カード（CSV手入力）は `disabled`、現金は `unsupported`。**この区別が要点で**、楽天カードに同期時刻が無いのは「古い」からではなく「同期していない」から。区別せずに「時刻が無い＝古い」とすると、同期していない口座を古いと呼ぶ誤判定になる。API は真偽値1つではなく内訳（`synced` / `stale` / `not_syncing` / `no_sync` / `unknown`）を返す —— 潰すと「銀行は今朝同期済み・カードは3週間前の手入力」がどちらに倒しても嘘になる。しきい値（7日）は**分布から出した値ではない**（観測1点）。日次cronが `oldest_sync_age` を残すので、貯まってから狭める。**読み方を4回間違えた記録**は ../simplememo-api/docs/freee-setup.md にある（`up_to_date` は存在しないフィールド／`update_date` は口座レコードの更新日／`wallet_txns.date` は取引日／詳細の404を「エンドポイントが無い」と読んだが実際はパス違い）。"
    },
    {
      "area": "⑦ 法人経営",
      "task": "仕訳・請求・領収書・月次締めの統合",
      "executor": "nobody",
      "evidence": [
        "docs/accounting-readback-evidence-20260910.md"
      ],
      "note": "2026-09-10: 既存freeeの明細・取引・公式仕訳帳に加え、個人口座の公式銀行CSVと振込詳細を取得した。会社関連の送金3件を実出金・受取先情報・法人側入金で照合し、外部決済5件と対応する銀行入金、カード月次請求の実引落も確認した。既存記帳2件と登録待ちを区別した。外部決済と銀行の共通ID、送金目的の内訳、同期後の法人明細、総額と手数料・税区分、期首残高を含む全社照合、必要な仕訳処理と月次締めは残る。既存仕訳をAI作成実績へ転用せず、executorはnobodyを維持する。",
      "blocker": "external_data",
      "unblocked_by": "取得済みの銀行原本・振込詳細・freee明細と公式仕訳帳を再利用する。法人側の同期後の原本、対応先未特定の入金、外部決済の帰属と内訳、期首残高・未登録明細・総額と手数料・税区分・配賦を照合し、必要な仕訳処理と月次締めを実行・検証する。取得済みの原本や認証を未取得として調べ直さず、読取成功だけで完了にしない。",
      "unlock": "bank_feed"
    },
    {
      "area": "⑦ 法人経営",
      "task": "税務・給与・社会保険・法定期限の管理",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/corporate-obligations.json",
        "scripts/check-corporate.mjs",
        "scripts/check-domain-expiry.mjs",
        ".github/workflows/seo-daily.yml",
        ".github/workflows/seo-check.yml"
      ],
      "note": "2026-08-22に台帳と検査を実装。**2026-08-25 に会社の事実が入り、6件中2件が実際に動く期限になった** —— 決算期2月末から法人税・地方税と消費税の申告期限を機械が導く（2027-04-30）。インボイス登録ありが確定したので、資本金や基準期間によらず課税事業者。**日付は台帳に直書きせず決算月から毎回計算する**ので、年をまたいでも古い日付が残らない。残る4件の未把握: Apple Developer の加入日・ドメイン更新日・社会保険の具体的な届出期限・法定調書の要否。**役員報酬ありも確定した**ので社会保険が該当することは決まった（従業員の有無ではなく役員報酬で決まる）。[2026-08-26] **この note と unblocked_by は、材料が届いた翌日から古いままだった。**「消費税は資本金と設立日が無いので未把握」と書いていたが、指している検査は既に期限を出していた。blocked_on を置いて、届いたことを機械が見るようにした\n\n**[2026-09-02] 6件すべてが機械の監視下に入った。executor を `ai_proposes` → `ai_executes_gated` へ。**\n\n最後まで残っていたドメインの更新日が、**週次の実行で RDAP から入った**（2027-01-30）。手で入れたのではなく `scripts/check-domain-expiry.mjs --write` が取得した値で、**外部の3経路（画面・外部調査のRDAP・オーナーのWHOIS）と一致した** —— 台帳が仕込んでいた答え合わせが、食い違いを出さずに閉じた。\n\nいま機械が持っているもの:\n\n    法人税・消費税      決算期（2月末）から毎回導出。**日付を直書きしない**\n    社会保険・法定調書  月日から毎回導出（fixed_annual）\n    ドメイン            RDAP から週次で取得（source: rdap）\n    Apple Developer     オーナー確認済（自動更新なしを4通りで確認）\n\n**人の個別承認は要らない。**期限が近づけば warning、欄が欠ければ CI が落ちる。オーナーが与えるのは「その義務が当社に当たるか」という事実（決算期・役員報酬・インボイス登録）で、**機械の実行を1件ずつ承認する形ではない。**\n\n**申告そのものは人のまま。**この行が数えているのは期限の管理であって、提出ではない（提出は⑦の別の行と士業の領域）。\n\n**あわせて `check-corporate.mjs` の「把握」の定義を直した** —— `confirmed_by_owner` だけを見ていたので、**機械が入れた権威ある値が「未把握」と表示され、しかも日付の検査を1つも受けていなかった**（期限切れ警告が飛ばされる）。出典と日付があり未確認の理由が無い行は把握とみなし、オーナー確認の行と同じ検査を受けさせる。**`confirmed_by_owner` を機械が立てる形にはしていない**（フラグ名が owner なので、機械が自己認証する経路を作らない）。"
    },
    {
      "area": "⑦ 法人経営",
      "task": "定型／非定型契約の分類",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/vendor-register.json",
        "scripts/check-vendors.mjs",
        "../simplememo-api/scripts/check-contracts.mjs",
        "../simplememo-api/data/contract-register.json",
        "scripts/check-contract-kind.mjs",
        ".github/workflows/seo-check.yml",
        "data/check-selftests.json"
      ],
      "note": "ベンダー台帳で「どの事業者とどんな関係があるか」までは機械が持つようになった。\n\n**[2026-08-28 訂正] 待っていた相手を間違えていた。**この行は `contract_docs`（契約書をリポジトリに置く）を待っていたが、この台帳自身が records で「**書面の契約書は無く、規約への同意で成立している**」と記録している。**存在しない書面を待っていた。**分類の対象は規約本文で、それは特定済み・指紋監視（**週1回・月曜**）・15/40マス読解済み。待っているのは残り34マスで、それは `vendor_terms`。\n\n**[2026-08-28 決定] 原本はどのリポジトリにも置かない。**git の履歴は消せず simplememo は公開。原本は既に居場所がある（規約＝各ベンダーの管理画面 / 請求書＝freee）ので、写しを作ると正が2つになり、古いほうを機械が読む事故を足すだけになる。\n\n**[2026-08-31 実測] この欄のマス数は古い。**`data/corporate-obligations.json` の `contract_review` を数えたところ、**44マスすべてが埋まっており `unreviewed` はゼロ**（risk 35 / ok 9）、11社すべてが `reviewed_by: \"human\"`。#726 / #728 / #731 / #732 で 08-28〜29 に埋め切られている。**「34マス未読」は事実でなくなった。**守る側も #733 で入った（`check-corporate.mjs` の `clauseGuard`）。\n\n**[2026-08-31] blocker を `missing_source_document` から `not_started` へ。****待っていた書面は「無い」のではなく「存在しない」** —— 書面契約が発生しておらず、対象は規約同意で、その台帳は既に手元にある。**「対象の書類がリポジトリに無い」は、この行については誤った待ち方だった。**\n\n**executor は動かしていない。**導く経路をまだ作っていないので、分類は誰も実行していない（`nobody` ではなく `ai_proposes` なのは、ベンダー台帳までは機械が持っているため）。**作ってから動かす。「材料が揃った」を「分類できている」と数えない。**\n\n**[2026-09-01] 導く側を作った。executor を `ai_proposes` → `ai_executes_gated` へ。**`scripts/check-contract-kind.mjs` が `data/vendor-register.json` と api の `contract-register.json` から種別を**導出**し、seo-check が毎回回す。手で書いた分類欄は作っていない —— **台帳に書くのではなく、台帳から導く。**\n\n導出: `terms_accepted_by` が在り書面が無い → 定型（附合契約）／書面が在る → 非定型／どちらも無い → **undetermined。standard に丸めない**（記録が無い＝問題なし、をやらない）。\n\n**今日の出力は11社すべて定型・非定型0件。**この行が数える側へ入る根拠は、分類が機械の出力になり、CIが食い違いで落ちるようになったこと。**非定型が現れたときの承認は人のまま**（権限表「契約・支払い・送金」が human_only）で、そこは渡していない。\n\n**空回りの疑いには入口で答えた** —— 実データを3通り壊して exit 1 を観測した（terms_accepted_by を消す／書面を入れて approved_by を \"ai\" にする／台帳に無い相手の書面を入れる）。`data/check-selftests.json` に demonstrated として記録。\n\n**隣が読めない回は照合していないと明示する。**CI に ../simplememo-api は無いので、書面との突き合わせは読めた回だけ。読めなかったことを「食い違い無し」に化けさせない。"
    },
    {
      "area": "⑦ 法人経営",
      "task": "責任上限・知財・個人情報・準拠法の条項検査",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/corporate-obligations.json",
        "scripts/check-corporate.mjs",
        "data/vendor-register.json",
        "scripts/vendor-terms.mjs",
        "scripts/vendor-clause-worksheet.mjs",
        "scripts/lib/contract-assessment.mjs",
        "docs/clause-inspection-execution-2026-09-07.md"
      ],
      "note": "2026-08-22に台帳と検査を実装。10社×4観点。**書面の契約書は無く、各社の規約への同意で成立している**ので、検査対象は規約本文であり確認は人が読むことでしか進まない。**現状40マスすべて unreviewed。**機械が守るのはベンダー台帳との照合（片方だけ増えると素通りする）と、riskと書いたら理由を要求すること [2026-08-26] **改定の検知だけを機械に移した**（scripts/vendor-terms.mjs・seo-daily）。**[2026-08-28 訂正] ここは「毎日取得」と書いていたが誤り。**週1回（月曜）。**scripts/vendor-terms.mjs は seo-daily.yml の中にあるが、**月曜ゲート（steps.when.outputs.snapshot）の内側**にある。したがって改定検知は毎日ではなく週1回で、**火曜に改定されたら、翌月曜まで reviewed は緑のまま残る（最大6日）。**配線が入ったのが 2026-08-26（水）なので、**指紋は全社まだ空で、初着弾は 2026-08-31。**一度 ok と書いた判定は、改定後も ok のまま残る —— **unreviewed（見ていない）より悪い。見たという記録が嘘を守る。**本文の指紋が変われば reviewed を unreviewed へ戻し、読み直しを起こす。**executor は動かない。**本文を読んで ok / risk を決めるのは法的判断で、そこは人のまま。機械が持つのは「いつの本文を見たか」だけ\n\n**[2026-08-31 実測] この欄のマス数は古い。**`data/corporate-obligations.json` の `contract_review` を数えたところ、**44マスすべてが埋まっており `unreviewed` はゼロ**（risk 35 / ok 9）、11社すべてが `reviewed_by: \"human\"`。#726 / #728 / #731 / #732 で 08-28〜29 に埋め切られている。**「34マス未読」は事実でなくなった。**守る側も #733 で入った（`check-corporate.mjs` の `clauseGuard`）。\n\n[2026-09-07 AI実行へ移管] 対象は規約本文の4条項検査。AIが公開原文を読んだ11分析を、人の過去判定と分けて保存。Firebaseの共通本文は公式のサービス対応・固有条件の読み合わせを根拠に明示参照し、複製しない。実データの作業一覧で11社44観点の判断・対応・原文根拠を照合した。本文の転載なしで読解を記録する経路により旧missing_source_documentを解消。契約承認・適用認定・DPA審査全体・別契約間比較を完了とはしない。この1件だけを数える。詳細はdocs/clause-inspection-execution-2026-09-07.md。",
      "since": "2026-09"
    },
    {
      "area": "⑦ 法人経営",
      "task": "取引先・送金先・利用サービスの許可リスト",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/vendor-register.json",
        "scripts/check-vendors.mjs"
      ],
      "note": "2026-08-22実装。10社すべてに money_flow / payment_method / approved_by / spend_cap_ref を持たせ、金銭が動く相手は human 承認と上限の参照先が無いとCIが落ちる。**ここに無い相手への支払いは許可されていない**という形。上限が設定されているのは AI実費と広報配信の2つだけで、残り8社は \"unset\"（理由つき）",
      "since": "2026-08"
    },
    {
      "area": "⑦ 法人経営",
      "task": "支出上限と重要支出の二者承認",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/spend-approvals.json",
        "scripts/check-financial-policy.mjs",
        "data/autopilot-cost.json"
      ],
      "note": "2026-08-22実装。**実際に効いている** — autopilot-cost.json の monthly_usd_cap は承認台帳の最新値と一致していないとCIが落ちる。つまり**承認記録を書かずに上限を動かせない。**変更幅が25%を超えるときは承認者2人。**AIは承認者になれない**（止めることは許しているが、金額を上げることは許さない）。3つの分岐を差し替えで検出確認。ただし**効いている対象はAI実費1件だけ**で、広告・契約は動く金額そのものがまだ無い",
      "since": "2026-08"
    },
    {
      "area": "⑦ 法人経営",
      "task": "契約・請求・納品・支払いの照合",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/service-reconciliation-execution.json",
        "docs/service-reconciliation-execution-20260909.md"
      ],
      "note": "2026-09-09、法人の既存会計サービス1取引で、AIが契約・請求・原本領収書・カード明細・既存会社仕訳・現在の役務提供を照合し、前払継続と税区分の例外を記録。原本PDFのSHA-256と28項目の検証を通し、現在時点の照合完了・例外ありとして保存。既存の手動仕訳、支払い、将来分の納品、税務承認、全取引や常設自動化サービスは加点しない。",
      "unblocked_by": "**[2026-09-01 訂正] この行は「freee に取り出し口があるか未確認」と書いていた。誤り。**\n\n**freee の Public API は 2026-08-27 から本番で動いている。**同じ領域（⑦法人経営）の「銀行・カード残高の読み取り（日次）」が `ai_autonomous` で在り、cron `freee_balance` が毎日 `/api/1/walletables` を叩いて 200 を受け取っている。**ひとり法人プランで使えるかという問いは、5日前に本番で答えが出ていた。**\n\n**しかも `/api/1/wallet_txns`（銀行明細）も既に叩いている。**照合に足りないのは請求書側（`GET /invoices`）だけ。\n\n**残っているのは実装だけなので `blocker` を `not_started` へ、`unlock` を外した。**鍵は既に本番にある（`FREEE_CLIENT_ID` / `FREEE_CLIENT_SECRET`、refresh token は KV の `freee:refresh_token`）。**新しい鍵は要らない。**\n\n**executor は `nobody` のまま。**照合は誰もやっていない。残高が読めていることを照合ができていることに数えない（隣の「仕訳・請求・領収書・月次締めの統合」が「**分けたのは、片方が動いたことで全体が動いたように数えないため**」と同じ規律を既に書いている）。\n\n[2026-09-09 実行] 円建ての既存会社サービスで実照合を完了。契約→請求→領収書の識別子を直接照合し、会計側の同日同額同社のカード明細1件と会社サービス使用料の既存仕訳を確認した。契約中のサービスで実際に当社の明細と仕訳を取得できたことを役務提供の現在証跡とする。前払原本はリポジトリ外に保持し所在・SHA-256を記録。年払いの将来提供や税区分は例外として残す。旧Anthropic取引の不足を埋まった扱いにせず、この実照合1件だけを移管。根拠は data/service-reconciliation-execution.json と docs/service-reconciliation-execution-20260909.md。",
      "$research_2026_09_01": "**この調査は外部ディープリサーチ経由で、原文を読んだ人間は鎖の中に居ない。**vendor-register が 2026-08-29 に同じ弱さを記録しているのと同じ種類。このセッションの WebFetch は freee ドメインも含めて塞がれている。\n\n**一番効く主張だけ裏を取ろうとして、取れなかった。**\n報告は「freee会計・freee請求書ともに Public API は**全プラン**」（support.freee.co.jp の記事 115000143186・更新 2026-03-18）と書いている。これが正しければ**ひとり法人プランのまま使える**ので、計画全体がここに乗る。\nWebSearch で同じ記事を引いたが、索引が返したのは**「対象プロダクトとご契約のプランによって異なります」という前置きの文**までで、**プラン別の表そのものは取れなかった。**否定もされていないが、確認もできていない。\n\n**確認と第一歩が同じ操作である**ことが、ここでは効く —— オーナーが freee の開発者ページでプライベートアプリを作れば、**作れた時点でプランの疑問は消える。**別途の検証ラウンドを挟む必要は無い。\n\n**報告が「見つからなかった」と書いた項目（推測で埋めない）:**\n    invoice → wallet_txn の直接的な外部キー … 銀行明細1行との1対1接続\n    Public API の追加料金に関する明文        … 無料と書いてある頁も無い\n    レート制限の具体的な数値                  … 存在することは書かれている\n    `read-only` という名称の OAuth scope      … GET だけに権限を絞るのは可能\n    CSV の定期自動エクスポート                … 手動エクスポートは可能\n\n**6項目を空欄で返してきたことが、この報告を信じてよい根拠のひとつ。**埋めろと言われた欄を埋めずに返すのは、推測で埋める報告より扱いやすい。\n\n**期日つきの注意: 2026-09-21 に `GET /invoices` の破壊的変更**（`limit + offset` が 10,000 以上のリクエストが制限対象）。当社の請求書件数では当面効かないが、**実装するなら日付範囲で取る形にしておく。**いま何も作っていないので期限台帳には入れない —— **壊れるものがまだ無い。**",
      "$my_error_2026_09_01": "**隣のリポジトリを見に行かなかった。**\n\nこの行の `evidence` は空で、隣の「銀行・カード残高の読み取り（日次）」は`../simplememo-api/src/freee.ts` / `test/freee.test.ts` / `docs/freee-setup.md` を**証跡として持っていた。**同じ領域の2行しか離れていない。\n\n**害は3つ出た:**\n  1. オーナーに「freee にAPIがあるか調べて」と外部リサーチを依頼させた\n  2. その報告の「全プランで使える」を裏取りできないと書いた —— **本番で5日間200が返り続けているのが裏そのものだった**\n  3. **～オーナーに2つ目のアプリを作らせた～** ← **これは起きていなかった（下で訂正）**\n\n**「確認と第一歩が同じ操作」も再発見だった** —— `docs/freee-setup.md` が 2026-08-25 の時点で「**§1 をやってみれば30秒で分かる**」と既に書いている。\n\n**なぜ起きたか。**外部の答え（GPTの報告）が来たので、それを台帳に流し込む作業になり、**手元にある事実と突き合わせる段を飛ばした。**このリポジトリが繰り返し警告しているのは「読めなかったものを異常なしと読む」誤りだが、**これは「読めるものを読まずに、外へ聞いた」誤り**で、向きが違う。**外から答えが来たときこそ、先に手元を見る。**\n\n**[2026-09-01 訂正] 3つ目の害は起きていなかった。**\n\nオーナーが freee の画面を見せたとき、「あなたのアプリ専用の Client ID、Client Secret が発行されました」というオンボーディング枠を、**その日に新規作成されたもの**と読んだ。**枠は常に出ている案内で、作成の記録ではない。**\n\n**アプリは最初から1つで、それが本番の連携そのものだった。**オーナーの「今日は作っていません」で止まった。\n\n**害はここでも1つ出た** —— 存在しない「アプリ2つ問題」を立て、削除の危険性・10秒でできる確認手順まで詳しく説明した。**問題そのものが無かったので、その説明は全部むだだった。**\n\n**同じ日に2回、同じ形で間違えている:**\n  1回目 … 隣のリポジトリを見ずに「APIがあるか未確認」と書いた\n  2回目 … 画面の枠を読んで「今日作られた」と書いた\n**どちらも、手元／目の前にあるものを確かめる前に、話を先へ進めた。**\n\n**残った害は2つで、こちらは実際に起きた:**\n  1. オーナーに不要な外部リサーチを依頼させた\n  2. 「全プランで使える」を裏取りできないと書いた（本番で5日間200が返り続けているのが裏だった）\n\n**副産物として1つ良いことがあった** —— この取り違えのおかげで、`../simplememo-api/docs/freee-setup.md` に**「下書き・非公開のアプリが本番そのもの。削除するな」**という警告が入った（simplememo-api#210）。**手順書には「止めかた」はあったが、アプリ自体の削除は書かれていなかった** —— そちらは再認可では戻らない。",
      "since": "2026-09"
    },
    {
      "area": "⑦ 法人経営",
      "task": "AI事業者のDPA・データ利用・SLA・撤退計画の審査",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/vendor-register.json",
        "data/vendor-operating-review.json",
        "scripts/check-vendors.mjs",
        "scripts/lib/vendor-operating-review.mjs",
        "docs/vendor-operating-review-2026-09-08.md",
        "docs/vendor-review-source-addendum-2026-09-08.md"
      ],
      "$previous_note": "2026-08-22にベンダー台帳を作成（10社）。何を渡していて・止まると何が起きて・代替があるかを機械検査する。**DPAの確認そのものは人の作業で、いま6社が未確認**。確認したら enforce_unreviewed を true にすると CI が守る [2026-08-26] **改定の検知だけを機械に移した**（scripts/vendor-terms.mjs・seo-daily）。**[2026-08-28 訂正] ここは「毎日取得」と書いていたが誤り。**週1回（月曜）。**scripts/vendor-terms.mjs は seo-daily.yml の中にあるが、**月曜ゲート（steps.when.outputs.snapshot）の内側**にある。したがって改定検知は毎日ではなく週1回で、**火曜に改定されたら、翌月曜まで reviewed は緑のまま残る（最大6日）。**配線が入ったのが 2026-08-26（水）なので、**指紋は全社まだ空で、初着弾は 2026-08-31。**一度 ok と書いた判定は、改定後も ok のまま残る —— **unreviewed（見ていない）より悪い。見たという記録が嘘を守る。**本文の指紋が変われば reviewed を unreviewed へ戻し、読み直しを起こす。**executor は動かない。**本文を読んで ok / risk を決めるのは法的判断で、そこは人のまま。機械が持つのは「いつの本文を見たか」だけ\n\n**[2026-08-29 訂正] `policy.enforce_unreviewed` は条項マスを守らない。**あのフラグは data/vendor-register.json にあり、守るのは **DPAレビュー**（personal_data が none でないのに dpa_reviewed が無いベンダー）で、条項の40/44マスとは別物。**実測した** —— 1マスを unreviewed に戻して check-corporate --check を走らせても exit 0。**条項マスを守る検査は存在しない。**改定で reviewed が戻されても、CIは何も言わない。\n\n**[2026-08-29 追記] 守る検査を作った。**`check-corporate.mjs` の `clauseGuard` が、**一度も見ていないマス**（`unreviewed_budget`・ラチェット。今は0）と**改定で戻されたまま放置されたマス**（`reset_grace_days`・14日）の2つで落とす。**実測: 1マスを unreviewed に戻すと exit 1。**（入れる前は exit 0 だった。）\n\n**猶予が要るのは膠着を避けるため** —— seo-daily は改定を検知して台帳をコミットするPRを出すので、即座に落とすと**そのPR自身が入らず、指紋の更新も入らず、翌週また同じ改定を検知する。**\n\n**[2026-08-31 実測] 未確認は6社ではなく9社。**`data/vendor-register.json` を数えた —— apple / resend / github / registrar が personal、cloudflare / google_cloud / search_console / firebase / appsflyer が pseudonymous で、**この9社すべてが `dpa_reviewed: null`。**確認済みは0社。**条項マスが埋まったこと（44/44）と混同しない** —— 別の欄で、別の文書を読む作業。",
      "$previous_blocker": "missing_source_document",
      "$previous_unblocked_by": "**[2026-08-31 実測] 「6社が未確認」は古い。**ベンダーが11社に増え、`personal_data` が none でない **9社すべてが `dpa_reviewed: null`**（確認済み0社）。`policy.enforce_unreviewed` も false のまま。**条項44マスとは別物**で、そちらが埋まってもこの行は動かない（2026-08-29 に実測で切り分け済み）。読む先は各社の DPA / Subprocessors / セキュリティ文書",
      "$previous_unlock": "vendor_terms",
      "since": "2026-09",
      "authority": {
        "domain": "外部サービスの運用審査",
        "ai_may": "既存利用範囲のDPA・データ利用・SLA・撤退計画を審査し、継続条件・未解決リスク・再審査条件を決定して適用する"
      },
      "note": "2026-09-08: 包括委任の下でAIが全14社（登録11・追加3）のDPA・データ利用・SLA・撤退計画を審査し、56観点の評価と条件付き既存利用継続を決定。追加の公開原文を読み、実プラン・ソース・復元実測と過去の人の審査を照合した。利用範囲拡大・契約変更・事故・撤退前は再審査。CIが対象漏れ、根拠/台帳の変更、期限切れ、契約承認や人の確認への誤変換を拒否する。人のDPA確認3社の日付と残るnullは維持。契約適用、実リージョン、SCC等の未読参照、未検証の移行・削除は各社のunresolvedに残し、是正済みとはしない。加点対象は4観点の運用審査・判断の実行であり、別行の条項検査・比較や是正・移行そのものではない。"
    },
    {
      "area": "⑦ 法人経営",
      "task": "董事会・株主・規制・契約記録の保存",
      "executor": "ai_proposes",
      "evidence": [
        "data/corporate-obligations.json",
        "scripts/check-corporate.mjs",
        "../simplememo-api/data/incidents.json",
        "../simplememo-api/test/incidents.test.ts"
      ],
      "note": "2026-08-22に台帳と検査を実装。5件中2件は所在があり（規約への同意・App Reviewのやり取り）、**3件は所在が決まっていない**（議事録・株主名簿・事故記録）。事故記録は「発生していない」のか「記録する場所が無い」のかを区別できていない\n\n**[2026-08-28] 所在が決まった。3件のうち1件は機械の側に入った。**事故記録は ../simplememo-api/data/incidents.json を作成し、あちらの test/incidents.test.ts が形を守っている。**空の entries が「起きていない」を意味する** —— ファイルが無い状態は「起きていない」を何も意味しなかった。\n\n議事録・株主名簿は**法が保管場所を本店と指定している**ので、リポジトリには置かない（入れても義務は果たされず、正が2つになる）。株主名簿は氏名・住所が載るため非公開リポジトリでも置かない —— git の履歴は消せない。\n\n**したがってこの行がこれ以上機械側へ寄ることはない。**残るのは実在の確認1回で、それは `corp_records` が持っている。\n\n**[2026-09-01] 2件は「無い」と確定した。**オーナーの明言。**そして義務は履行されていない** —— 会社法318条2項（株主総会議事録・10年・本店）と125条1項（株主名簿・常時・本店）は、**株主が1名でも外れない。**取締役会は非設置なので371条（取締役会議事録）は発生しない。\n\n**「無い」と記録したことを「解決した」と読まない。**台帳が良くなったのは「無いと確かめた」が読めるようになった点だけで、**書面は依然として存在しない。**各 record の `obligation_status: \"unmet\"` がその状態を持つ。\n\n**株主総会そのものは開かれている可能性が高い** —— 決算期は2月末で、定時株主総会での計算書類の承認は法人税申告の前提になる。税理士が決算のたびに議事録を作っているケースもあるので、**「手元に無い」＝「存在しない」とは限らない。**確認事項として税理士へ回した。\n\n**[2026-09-01 訂正] 上の「2件とも無い」は誤りだった。**オーナーへ議事録と株主名簿を**2つまとめて聞き、「ない」という1つの答えを2つの行に配った。**実際に無いのは議事録だけで、**株主名簿は設立時の書類一式に含まれている**（125条1項は満たされている）。\n\n**まとめて聞いたから、まとめて答えが返った。**根拠条文も作成主体も違うものを1問にした私の誤り（318条2項＝会社が毎回作る／125条1項＝設立時に作って変動時に更新する）。**次に人へ事実を聞くときは、1行に1問。**\n\n**議事録は「作らない」とオーナーが決めた**（318条2項の備置義務は株主1名でも外れないことを伝えた上での判断）。`decision` 欄に持たせてあり、`obligation_status` は `unmet` のまま —— **決めたことで義務が消えるわけではない**ので「解決済み」にはしない。\n\n**行の分類は変わらない。**`physical_human` としたのは「書面が無いから」ではなく**「法が保管場所を本店と指定していて、機械がそこに居られないから」**。株主名簿が在ることが分かっても、機械が持てるようにはならない。**到達可能上限 82.9% も動かない。**",
      "blocker": "physical_human",
      "unblocked_by": "**[2026-09-01] 待ちは終わった。そして、この行はここで止まる。**\n\nオーナーが「ない」と回答した（議事録・株主名簿）。所在（本店＝事務所）は同日に確認済みで、**そこに置かれていない**という答え。`existence_confirmed_at` に日付が入り、`corp_records` の述語3つはすべて満たされた。\n\n**機械はここで「行を動かせ」と押してきた** —— `autonomy-gap --check` が「入口はもう開いているのに待ち扱いのまま」と出した。**押し返した。**\n\n**理由: 5件のうち2件は、機械が持てるようになる日が来ない。**\n\n    vendor-contracts          各ベンダーの管理画面       在る（外）\n    app-review-correspondence ASC ＋ docs/reports        在る（一部は機械側）\n    incident-records          api/data/incidents.json   **機械が持つ**（test付き）\n    board-minutes             本店                       **無い**・318条2項・作らない決定\n    shareholder-register      本店                       **在る**（設立時の書類一式）\n\n下2件は**法が保管場所を「本店」と指定している。**リポジトリに入れても義務は果たされず、正が2つになるだけ。株主名簿は氏名・住所を載せるので、**非公開リポジトリでも置かない**（git の履歴は消せない）。**オーナーが今から作っても、この構図は変わらない** —— 作られた書面は本店に置かれ、機械が持つのは所在の指示のままになる。\n\nしたがって `blocker` を `external_data`（到達可能）から `physical_human`（到達しない）へ移し、`unlock` を外した。**到達可能上限が1件下がる。**\n\n**これは数字を下げる向きの変更で、機械の催促と反対**である。前任が note に「**この行がこれ以上機械側へ寄ることはない**」と明記していたのを、+0.5% のために読み替えないこと。\n\n**旧 unblocked_by（保存）:** 本店に議事録・株主名簿が実在するかの確認（1回）。**所在は 2026-08-28 に決まった** —— 議事録・株主名簿は本店（会社法318条2項/125条1項）、事故記録は ../simplememo-api/data/incidents.json（作成済み・検査付き）"
    },
    {
      "area": "⑦ 法人経営",
      "task": "物理業務発注後の写真・受領・品質確認",
      "executor": "nobody",
      "evidence": [],
      "note": "3リポジトリに証跡ゼロ",
      "blocker": "physical_human",
      "unblocked_by": "現物の受領確認"
    },
    {
      "area": "⑦ 法人経営",
      "task": "倫理・評判・長期影響の独立監査",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/audit-charter.json",
        "scripts/check-audit-independence.mjs"
      ],
      "note": "2026-08-22実装。独立監査の4観点のうち ethics_reputation がこれ（5項目）。利用者に見えない不利益変更・実在しない実績の装い・人間だと誤認させる自動投稿・競合を貶める言及・**AIが書いたと分かる形になっているか**。**短期の指標では絶対に検知できない**種類の劣化なので別系統に置いた。**まだ一度も走らせていない**",
      "since": "2026-08"
    },
    {
      "area": "⑦ 法人経営",
      "task": "エージェントごとの権限・認証情報・失効手順",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/credential-expiry.json",
        "scripts/check-credentials.mjs",
        "data/emergency-stop.json",
        "data/authority-matrix.json",
        ".github/workflows/seo-check.yml"
      ],
      "note": "2026-08-22実装。鍵13件それぞれに**使う経路・失効のさせ方・失効させると何が止まるか**を持たせ、ワークフローが実際に読む secret を現物から走査して台帳との食い違いを落とす。`--stop <経路>` で「この経路を止めるにはどれを失効させるか」に答える。**この作業で穴が1つ出た** — 緊急停止の最終手段は「credential-expiry.json の鍵を無効化する」と書いてあったのに、主系を止める鍵（GH_PAT）が台帳に無く、使用中の secret 11件のうち載っていたのは3件だけだった。最後の手段が指す先が空だった。残る弱さ: **失効操作そのものは人**（各社コンソールへのログインが要る）。critical 5件のうち4件は期限が未把握のまま",
      "since": "2026-08"
    },
    {
      "area": "⑦ 法人経営",
      "task": "法務・税務・労務・事故時の専門家エスカレーション",
      "executor": "human_only",
      "evidence": [
        "data/authority-matrix.json"
      ],
      "note": "方針のみ。手順・連絡先・停止手段は未整備。 **[2026-08-25] 税理士と社会保険労務士の両方がついていることをオーナーが明言した。**「士業が居るか」は未把握でなくなり、**領域ごとの向き先も決まった**（税務→税理士 / 社会保険→社労士）。**ただし連絡先・エスカレーション手順・停止手段は依然として未整備。**居ることと、機械が繋げることは別。実際 corporate-obligations の未把握5件のうち2件は「士業に聞けば埋まる」状態で止まっている\n\n**[2026-08-28 訂正] 向き先の片方は存在しなかった。**この欄は「税務→税理士 / 社会保険→社労士」と書いていたが、**社労士は雇っていない**（社員がいないため・オーナー確認）。corporate-obligations の social-insurance も「社労士がついているので期限はそちらに確認する」と書いており、**居ない相手に確認する、と2か所に書いてあった。**確認先の実在を誰も検査していなかったのが原因。\n\n**手順・停止手段・起案は作った**（data/expert-escalation.json / scripts/check-expert-escalation.mjs）。⑧の返信ゲートと同じ形で、宛先が外部の専門家なので閾値は厳しい —— 送るのは台帳にある reviewed な文面だけ（送信時に作らない）／向き先が依頼済みであること／元の未把握がまだ未把握であること／金額・資格情報・利用者の識別子が入っていたら落とす／日次1通・同じ相手へ7日おき・返事待ち上限2。**連絡先は公開リポジトリに置かない** —— 第三者の個人情報なので Worker の secret に置き、台帳が持つのは在り処だけ（address_source に `@` が入っていたら検査が落とす）。\n\n**分類は動かさない。**残っているのは実行側（simplememo-api の送信経路）とオーナーが enabled を立てること。**「経路ができた」を「送った」と数えない** —— 段階公開やレビュー返信と同じ基準",
      "blocker": "physical_human",
      "unblocked_by": "対人・法的責任。**[2026-08-28] その理由は正しいが、範囲が広すぎた** —— 判断（税務・社会保険の解釈）は人のままでよく、機械が持てるのは「誰に・何を・いつまでに聞くか」の起案と送信。起案と門は作った（data/expert-escalation.json）。残るのは実行側（simplememo-api の送信経路と EXPERT_TAX_EMAIL の secret）と、オーナーが enabled を立てること"
    },
    {
      "area": "⑧ カスタマーサポート",
      "task": "問い合わせの自動分類",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/inquiry.ts",
        "../simplememo-api/migrations/0020_inquiries.sql",
        "../simplememo-api/test/inquiry.test.ts"
      ],
      "note": "2026-08-22実装（simplememo-api・24テスト）。**AIに判定させず規則で分ける** — 回帰の合否をAIに判定させない設計と同じ理由で、分類の誤りは見落としとして静かに積み上がる。分けられないものは**「その他」ではなく unclassified**（その他は見返されないが、未分類は見返される）。重い用件（個人情報・退会・返金）を先に当て、当たったら自動で人へ上げる。**受け口は既定オフ**（INQUIRY_ENABLED）で、公開ページを mailto から切り替えるかは製品の判断。テストが実バグを検出した — 「送信できません」が「できな」に当たらず未分類に落ちていた",
      "since": "2026-08"
    },
    {
      "area": "⑧ カスタマーサポート",
      "task": "問い合わせへの自動回答（承認済みテンプレート）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/reply-gate.ts",
        "../simplememo-api/data/reply-policy.json",
        "../simplememo-api/src/inquiry.ts",
        "../simplememo-api/test/reply-gate.test.ts",
        "../simplememo-api/migrations/0026_inquiry_auto_replied.sql"
      ],
      "note": "2026-08-26実装（オーナー判断: 品質ゲート通過で自動送信）。**承認はテンプレート単位で先に取る** — メールは取り消せず、権限表の一番の規則が「不可逆な領域は承認制」なので生成文をそのまま送る形は取れない。data/reply-policy.json の編集（レビュー付きPR）がその承認で、個別送信の承認は要らない。ライフサイクルメールと同じ構造。\n\n**受付時に返す。あとから返さない。**inquiries は宛先を平文で持たない（email_hash のみ）ため、後追い返信にすると宛先を保存することになりプライバシー設計の後退になる。\n\n判定は全部決定論。返金・退会・個人情報はテンプレートを置いていない（分類器が先に弾くが登録簿でも二重に落ちる）。落ちた問い合わせは open のまま残る — **当たらなかったことを「返した」にしない。**\n\n**2026-08-26に受け口を開け、実送信へ昇格した。**INQUIRY_ENABLED=true / INQUIRY_AUTOREPLY_DRY_RUN=false（上限は5で開始。policy側の既定30へは実績を見てから）。本番D1に migration 0026 を適用済みで、本人確認済み274件・配信停止21件が突き合わせの対象。公開ページのフォームも設置した（mailto は残す）。\n\n**開ける前に3つ塞いだ。**/v1/inquiry は App Check の対象外＝無認証の公開POSTで、自動返信を足した時点で「任意の第三者へメールを送らせる経路」になる。(1) verified_registrations にあり配信停止されていない宛先にだけ返す (2) 受付そのものにIP上限（IPハッシュ×UTC日5件・survey と共用） (3) CORS は問い合わせ2経路・許可オリジン2つだけで Origin を反射しない。\n\n**まだ1件も送っていない**（問い合わせ0件・main へのマージで本番反映）。空の実績を「安定している」と読まないこと。",
      "since": "2026-08"
    },
    {
      "area": "⑧ カスタマーサポート",
      "task": "障害案内の一斉配信",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/service-notice.ts",
        "../simplememo-api/src/service-notice-monitor.ts",
        "../simplememo-api/test/service-notice-monitor.integration.test.ts",
        "../simplememo-api/test/service-notice-monitor.test.ts",
        "../simplememo-ios/SimpleMemoTests/ServiceNoticeTests.swift",
        "docs/service-notice-tested-readiness-20260913.md",
        "data/service-notice-readiness-20260913.json"
      ],
      "note": "**旧行から切り出した。**旧行は「回答・返金・障害案内」で、自動化できた回答と、権限表で人に残した返金（⑨に別行がある）と、未実装の障害案内が1行に入っていた。混ぜると、どれか1つができた時点で行が動く。障害案内は宛先の名簿と配信基準の設計が要る\n\n**[2026-08-28] この行の性格が変わった。プロダクトの機能ではなく、契約上の義務になった。**⑦の条項検査で Apple Developer Program License Agreement §3.3.3(C) を読んだところ、**利用者へのデータ侵害通知が契約で約束されている**（You agree to notify Your users ... in the event of a data breach）。\n\n**つまり「まだ作っていない機能」ではなく「約束したのに実行できない動作」。**優先順位の意味が変わるので、ここに書いておく。経路が2つとも閉じている事実（下記 unblocked_by）は変わらない —— 変わったのは、開けないままでよいかどうかの判断材料のほう。data/corporate-obligations.json の contract_review.apple.$personal_data に同じことが書いてある。\n\n[2026-09-13 完了条件変更] 返金・課金回復と同様のテスト済み運用準備を提案し、オーナーが「他と被らないなら進めて」と指定。task134だけを対象に、既存の公開案内API・アプリ内バナー経路のテストと、毎時の本番公開応答照合・自然発火・既存継続監視を完了条件とした。APIのactive/期限/撤回/改訂/キャッシュ/失敗と、実workerd・D1への監視記録、iOSのHTTP→キャッシュ保持→改訂→再起動復元→null撤回を検証。実障害の告知、全利用者への到達、実機E2E、法的・契約上の通知義務の充足は未確認で別の観測として保持する。メール同意を転用せず、本番fixtureや架空の障害は作らない。毎時の標本観測なので全revisionや観測間の可用性を証明しない。初回の実障害案内で二重加点しない。変更直前162/178=91.011236%、変更後163/179=91.061453%、増分約0.050217ポイント。全203件と定義対象192件は不変。",
      "since": "2026-09",
      "acceptance_basis": "test_verified_readiness_and_active_production_monitoring",
      "production_service_notice_observed_at": null
    },
    {
      "area": "⑧ カスタマーサポート",
      "task": "App Store レビュー返信",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/review-replies.json",
        "scripts/check-review-replies.mjs",
        "data/review-intake.json",
        "data/authority-matrix.json",
        "data/review-gate-pin.json",
        ".github/workflows/seo-check.yml",
        "../simplememo-ios/scripts/asc_review_reply.rb",
        "../simplememo-ios/data/review-responses.json",
        "../simplememo-ios/data/review-reply-gate.json",
        "../simplememo-ios/.github/workflows/asc-review-reply.yml"
      ],
      "note": "**2026-08-27、実際に投稿した。**run 33059048323 で3件 —— レビュー返信を機械が公開したのはこれが最初。記録は ../simplememo-ios/data/review-responses.json（response_id は Apple が返した値）。state は3件とも PENDING_PUBLISH で、**「POSTが通った」と「App Store に出た」は別。** **上書きしないことも実測した** —— 投稿直後に取り直したら ASC は 8/8 返信済みを返した。**PENDING_PUBLISH でも has_response=true になる**ので、翌日以降の実行は全件 hold する。 【境界】2026-08-27 にオーナーが「公開だけを人が承認する」から**「品質ゲートを通れば自動投稿」**へ変えた（権限表にゲート付き例外）。判断は公開側（evaluateAutoPost / planAutoPost）、実行は非公開側（ASCの鍵があちらにしかない）で、**ゲートの写しはあちらに置いていない。**指紋で留め、両側のCIで照合する。 【落とすもの】捌いていないレビュー / 期日・版の約束 / 個人情報 / 禁止表現と古い事実 / ★2以下 / 返金・法務・個人情報・保安・データ消失 / 日次上限3 / kill_switch / **すでに返信が付いているレビュー**（Apple の POST は上書きで、人が書いた公開返信を消しうる —— この防壁は初回の実データで実際に2件を止めた）。 【止まった回も残す】最初の実投稿は**ゲートの指紋がずれていて止まった**（run 33058628758）。公開側の写しだけ更新して非公開側を忘れたため。鳴子は「2か所に書け」と名指ししていたが**散文は止める力を持たなかった**ので、ios の qa-static に機械の照合（--check-gate）を足した。 self-test はゲート側57件・実行側34件"
    },
    {
      "area": "⑧ カスタマーサポート",
      "task": "FAQとリリース内容の同期",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/check-public-facts.mjs",
        "faq.html",
        "data/site-constants.json",
        "scripts/check-store-facts.mjs",
        ".github/workflows/seo-daily.yml"
      ],
      "note": "2026-08-22実装。FAQ・トップ（日英）・llms.txt・運営者情報の**散文**を site-constants / benchmark と突き合わせ、旧アプリ名・古い起動時間・廃止済みトライアル・価格ドリフトで落とす。廃止済みトライアルは景表法・ストア審査上のリスク対応で消したもので、それまで「出現回数0」を確かめていたのは人の目視だった。**リリースノート本文との突き合わせは隣リポジトリのためCI外** [2026-08-22追記] **公開表示の鮮度**も機械が見るようにした。評価（4.4）と件数（22）は JSON-LD の aggregateRating として12ページに出ているのに、どちらも人が App Store Connect を見て手で書いた値で、台帳のメモにも「NOT machine-verified」と書いてあった — **古くなっても誰も気づかない。**CIは45日を超えた確認日で落とす（ネットには触らない — PRのたびに外部APIを叩くと向こうの不調でCIが赤くなり、やがて無視される）。実物との突き合わせは日次ワークフローの --net で行う（**GitHubのランナーは itunes.apple.com に到達できる**が、エージェントのサンドボックスはプロキシがCONNECTを拒否するので確認できない）。**件数0で平均を出していないか**も見る — 実体の無い集計評価は公開してはいけない表示",
      "since": "2026-08"
    },
    {
      "area": "⑧ カスタマーサポート",
      "task": "CSAT計測",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/inquiry.ts",
        "../simplememo-api/src/reply-gate.ts",
        "growth/scripts/ingest-asc.mjs"
      ],
      "note": "2026-08-22。**計測する接点のうち「問い合わせ」はできた**（inquiry.ts）が、返信の自動化が無いので発火しない。answered のものだけ受ける設計にしてあり、返信を人がやった件だけ測れる。**まだ1件も測っていない** **[2026-08-25] 返信の下書きまでは出るようになった**が、CSAT は answered のものだけを受ける設計なので、**投稿が人の手で行われるまで依然として発火しない。** **[2026-08-26] 問い合わせ側の発火経路が閉じた。**自動回答が status を answered にするので、そちらは人手を介さず測れるようになった（レビュー返信は投稿が人のままなので、あちらは従来どおり）。auto_replied 列で「自動で返した件」と「人が返した件」を分けて読める —— **混ぜると、自動返信を入れてよかったのかが永久に分からない。****まだ1件も測っていない**（問い合わせ0件）"
    },
    {
      "area": "⑧ カスタマーサポート",
      "task": "重大案件の有人移管",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/escalation-rules.json",
        "scripts/check-escalation.mjs",
        "data/authority-matrix.json"
      ],
      "note": "2026-08-22実装。実行判定が返す故障・縮退コード5件と、運転台帳に**実際に現れた** failure_class 4件の全部に規則が要る（規則の無い種別があると落ちる）。危機領域は stop_automation: true を強制。**owner_direct の経路は未整備**で、名前が付いただけであることも台帳に書いてある",
      "since": "2026-08"
    },
    {
      "area": "⑧ カスタマーサポート",
      "task": "問い合わせからIssueと回帰テストを作成",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/.github/workflows/classifier-gaps.yml",
        "../simplememo-api/src/classifier-gaps.ts",
        "../simplememo-api/scripts/generate-classifier-tests.mjs",
        "../simplememo-api/test/classifier-gaps.test.ts",
        "../simplememo-api/src/inquiry.ts",
        "../simplememo-api/.github/workflows/repro-facts.yml"
      ],
      "note": "実物から自動生成する側が 2026-09-05 に1周動いた（Issue #248 と test/classifier-gaps.generated.test.ts）。手動の実績は Watch同期4往復→v4.9.30→回帰テスト化",
      "since": "2026-09",
      "unblocked_by": "**[2026-09-05] 実走を観測したので executor を動かした。**\n\n`simplememo-api/.github/workflows/classifier-gaps.yml` が実データで1周し、**Issue と回帰テストの両方が実物の問い合わせから自動でできた**（run 33948277349・写しは 78bc2a5）。\n\n    問い合わせ 27件 / unclassified 15件 / 順位が上の規則を外していた 6件\n    出た語形    同期 + できていません（実物2件）\n    作られた物  Issue #248 と it.fails の回帰テスト\n\n**そして直った。**「同期できません」は当たるのに「同期できていません」が unclassified に落ちていて、この形で書いた実物2件には自動返信が1通も出ていなかった。規則を直すと生成側の `it.fails` が落ちて気づける形にしてあり、実際に落ちた（simplememo-api 1.5.27）。\n\n**本文は出していない。**出るのは RULES の literal（話題語）と、ひらがなのみ・12文字以下・否定/可能の標識が先頭6文字以内・**2件以上の問い合わせに出現**を全部満たした語形だけ（許可制。オーナー判断 2026-09-05）。残っている risk は `simplememo-api/src/classifier-gaps.ts` の冒頭に書いてある。\n\n**②「問い合わせから再現テストを自動生成」は動かしていない。**同じ仕組みが両方の題名に当たるように見えるが、②は「② バグ修正」の下にあり、証跡が iOS の `REGRESSION_TEST_TEMPLATE.md`・note が「Watch同期」と、**製品バグの再現を指している。**分類器の欠陥で満たしたとは言い切れないので据え置く。",
      "unlock": "inquiry_facts"
    },
    {
      "area": "⑧ カスタマーサポート",
      "task": "ライフサイクルメール（歓迎・確認・リマインド）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/lifecycle.ts",
        "../simplememo-api/src/reminder.ts"
      ],
      "note": "cronで自動送信。DRY_RUN/KILL_SWITCH/DAILY_CAP付き"
    },
    {
      "area": "⑨ マネタイズ",
      "task": "価格・プラン・ペイウォールの実験",
      "executor": "nobody",
      "evidence": [],
      "note": "課金は不可逆で既存契約者への影響が読めない。権限表でAIは提案もしない扱い",
      "blocker": "policy_boundary",
      "unblocked_by": "権限表で AI は提案もしない（既存契約者への影響が読めない）",
      "authority": {
        "domain": "価格・プラン・無料枠の変更",
        "human_only": "すべて"
      }
    },
    {
      "area": "⑨ マネタイズ",
      "task": "オンボーディング改善（課金導線）",
      "executor": "ai_proposes",
      "evidence": [
        "../simplememo-ios/docs/reports/ONBOARDING_REDESIGN_2026-08-06.md",
        "docs/execution-priority-review-20260909.md",
        "docs/quota-physical-publication-20260912.md",
        "../simplememo-ios/SimpleMemo/ComposeViewController.swift",
        "docs/physical-quota-cold-session-20260912.md",
        "docs/gated-publication-execution-20260913.md",
        "docs/app-store-release-5.8.66-observation-20260919.md"
      ],
      "note": "データ起点の再設計。実施は人の判断\n\n**[2026-08-28] 到達可能側から外した（分類の訂正）。**2026-08-27 のオーナー判断は「**お金周りを除いて**渡す」で、課金導線はその除外側。\n**害は件数ではなく向きに出る** —— `--plan` が「作れば進む」と言い続け、天井が実際より高く出る。到達可能な件数は減るが、**下がった天井のほうが本物。**\n\n[2026-09-09] 最新の包括委任に合わせて古い権限待ちを解消。価格・無料枠・StoreKit権利を変えない課金導線の実装・適用をAIへ委任する。変更の実行証拠はまだ無いためai_proposesを維持し、実行率を加点しない。\n\n[2026-09-09 実装後] iOS PR #454は最終コミットのCI成功後、main 8ac29b4e558b73dc73bd6a0e6105234915632cd8へマージ済み。無料枠の4回目で課金画面を直接表示し、価格・権利は変更していない。Free・期限切れ・Premiumの3経路をSimulatorで確認し、旧導線に戻した変異は対象テストで失敗した。実適用は未確認のためai_proposesを維持。未着手から検証・配信待ちへ訂正し、再実装や小幅加点だけのTestFlightを優先候補にしない。\n\n[2026-09-12 部分実機確認・一般公開] 同じ5.8.54/1342の既存開発者Freeモードで3通送信・4通目の価格画面への直接遷移・閉じた後の下書き保持・カウント3を実機観測。検証モードOFF、Premiumと原下書きを復元済み。ASC段階公開ACTIVEと一般公開ページ5.8.54も照合した。ただし端末の初回レビュー履歴は不明で、変更前コードでも成立する経路の可能性が残る。公開側の既存条件も未証明。独立レビューの指摘に従い、今回の部分実機確認・公開観測ではai_proposesを維持する。追加TestFlightなし。\n\n[2026-09-13 公開経路の実装・反映] iOS PR500の最終CI成功後にmainへマージし、委任公開を有効化。API PR314で公開直前の停止証拠を読めるようにした。5.8.56はASC審査版の不一致で停止。既存5.8.54は対象版観測の非公開保存・読戻しまで成功したが、公開処理は実機記録のASC版ID不足で停止。Appleへの変更要求と公開予約は0件。健康度を含む公開条件の通過と次の実適用は未確認のためexecutorを維持する。\n\n[2026-09-19 5.8.66/1671 一般公開の独立確認] App Store Connect の GET-only 状態確認 run 35387187929 で 5.8.66 / build 1671 が READY_FOR_DISTRIBUTION、review submission 1130af2f-aba2-465b-9c1d-6ed073be73cf が COMPLETE になったことを確認。公開 iTunes lookup でも version=5.8.66 / currentVersionReleaseDate=2026-09-18T19:33:43Z を独立確認した。ただしこの版の提出 run 35359256581 は submit-review.yml の個別承認ラッパーから review-submit.yml を呼び、gated_publication を渡さないため RELEASE_POLICY=after_approval だった。2026-09-13 に定義した委任公開の独立ゲート（MANUAL→健康度・承認6h・kill7d等→asc-publish-version）を通っていない。したがって公開済みという事後事実を事前ゲート通過へ読み替えず、今回もexecutor・AI実行率は変更しない。次の加点は、standing delegation の gated_publication 経路で正当な次期版が公開要求受付→公開readbackまで完走した場合に限る。",
      "blocker": "verification_pending",
      "unblocked_by": "5.8.54/1342の追加実機確認で、アプリ終了・新プロセス・24時間より前の保存日時の不変と出荷ソースを照合し、旧レビュー分岐に該当する条件で4通目が直接価格画面へ進む証拠を回収した。初回分岐の実機確認は再実行しない。残るのは公開側のクラッシュ率・kill等の独立条件と適用の証拠。公開の事後観測を事前ゲート通過へ読み替えず、ai_proposesを維持する。新しい小幅TestFlightや再提出は不要。 2026-09-13: 委任公開の独立ゲート接続はmain反映済み。次の正当な公開では対象版と一致する実機記録・ASC版/ビルドID、同一確定週の健康度、6時間の承認待機・7日のkill待機等を満たし、要求と公開状態を照合する。過去の自動公開や今回の読取りだけでは加点しない。",
      "unlock": "impl_onboarding",
      "authority": {
        "domain": "オンボーディングの課金導線改善",
        "ai_may": "既存の価格・権利を維持したオンボーディングの課金導線を設計・実装し、既存の品質・配信ゲートを通して適用する"
      }
    },
    {
      "area": "⑨ マネタイズ",
      "task": "プレミアム機能の設計判断",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/docs/adr/ADR-002-premium-benefit-scope.md",
        "../simplememo-ios/data/premium-benefit-decision.json",
        "../simplememo-ios/SimpleMemo/PaywallViewController.swift",
        "docs/premium-benefit-execution-20260908.md"
      ],
      "note": "2026-09-08、オーナー包括委任のもとCodexがPremiumの価値を利用上限解除と設定済みObsidian専用保存へ絞る設計を採用し、購入画面へ適用した。無料でも使える速度と優先サポート運用の裏付けがない一律表示を特典から外した。価格・無料枠・StoreKit権利は変更していない。変更SHA aea30f2d221c197c953d04fa676cb3b9fa0a1029 の静的QA・Localization Parity・Xcode CloudビルドとFastUnitが成功し、PR #441をmainへマージ済み（0a3d4ac8d9148576ecf0b84f97f64181f40e8e26、04:34:24Z）。設計判断1件の実行であり、TestFlight追加配信、課金導線の本番改善、購入率・解約率の効果へ重ねて加点しない。",
      "since": "2026-09",
      "authority": {
        "domain": "プレミアム機能の設計判断",
        "ai_may": "既存の有料権利と実装を照合し、Premiumの価値・表示範囲を決定して適用する"
      }
    },
    {
      "area": "⑨ マネタイズ",
      "task": "解約理由分析",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/asc_subscription.rb",
        "../simplememo-ios/scripts/asc_analytics.rb",
        "../simplememo-ios/.github/workflows/asc-analytics.yml",
        "../simplememo-api/src/autopilot-report.ts",
        "../simplememo-ios/SimpleMemo/CancelFlowManager.swift"
      ],
      "note": "**[2026-08-26] 前提が間違っていた。**この欄は長らく「Apple が解約理由をくれるか未確認」と書いていたが、`Cancellation Reason` 列は **2026-08-25 の取得で既に届いていた**（Subscription Event Report / State Report のどちらの columns にも入っている）。読めなかった理由は Apple 側ではなく**こちらの保存の形**で、asc_analytics.rb が残すのは数値列の合計だけだった。解約理由は文字列なので合計対象に入らず、**列名だけが残って中身は1件も残っていなかった。**「取れない」と「捨てている」を取り違えていた（data/operating-memory.json om-2026-08-26-breakdown）。\n\n取得側に名指しの分類列 × 名指しの測定列の内訳を足し（BREAKDOWN_DIMENSIONS）、読む側を asc_subscription.rb として asc-analytics.yml の日次に配線した。**ただし 2026-08-26 時点で読めた項目は 0/3。**手元にある取得結果は内訳を持つ前の版なので no_breakdown を返す。**次の定時実行（毎日 20:30 JST）で決まる。**\n\n**空欄しか無い可能性は残る。**Apple 側で解約理由は任意項目であり、埋まらないほうが普通。読む側は空欄を捨てず `(空欄)` として数え、all_blank を readable と区別する ——**「解約理由が読めなかった」を「解約が無かった」と読ませないため。**空欄だった場合、⑨を実物にするにはアプリ内で理由を聞く導線が要る（未実装）。実施は引き続き人の判断なので ai_proposes のまま\n\n**[2026-08-26 決着] 空欄だった。**予定の定時実行（20:30 JST）を待たずに asc-analytics.yml を手動で回して確かめた。取得は成功し、内訳つきで降りてきて、`asc_subscription.rb` は 3項目中2項目を読めた（契約の状態 155/33・契約イベント 4件）。**しかし `Cancellation Reason` は列も値も届くのに、値が全部空欄**（all_blank）。上に書いてあった「空欄しか無い可能性」がそのまま当たった。\n\n**したがってこの行はもう『データ待ち』ではない。**待っていたものは降りて、空だと分かった。実物にするには**アプリ内で理由を聞く導線**が要る（未実装）。ブロッカーを external_data から not_started へ移した —— **降りない物を待ち続ける行にしないため。**\n\n**[2026-08-26 実装] 詰まっていたのは聞く側ではなく読む側だった。**上の unblocked_by は「解約時にアプリ内で理由を聞く導線」が要ると書いていたが、**その導線は既にあった** —— CancelFlowManager が v5.7.9 からイベントを送り、v5.7.11 で `reason` も乗るようになっている（SceneDelegate から配線済み）。本当に無かったのは**集計する経路**で、`cancel_flow_*` は `src/analytics.ts` の allowlist とコメントにしか名前が出てこなかった —— 2026-08-15 から入っているのに、**11日間、誰も読んでいなかった。**\n\n`src/cancel-flow.ts` を作って日報へ配線した。本番D1を引くと11日ぶんで9行あり、**2026-08-24 に引き止めが1件成立していた**（reason=price → offer=free_plan → exit=stay）。フロー導入後の初めての成功で、誰も知らなかった。\n\n**率は出さない。**実データは表示4件 / 理由を答えた1件で、CLAUDE.md の運転規則（根拠にしてよいのは 0/非0 の事実か、分母20の累積）に従い分母が20に届くまで率を1つも出さず「分母 4 < 20」と足りないことごと書く。引き止めの成立件数だけは率ではなく事実なので n=1 でも出す。`reason:\"none\"`（未選択の番人の値）は理由の内訳に混ぜない。\n\n**分類を ai_proposes → ai_executes_gated へ。**集計は毎朝の日報として出て、人が手を動かして初めて分析が走る段は無い。「読めなかった / 出ていない / 答えが無い」を別々の文面で出し、13通りの壊し方すべてで検査が落ちることを確認した。**「何を作るか」の判断は人のまま**で、それはこの行ではなくプロダクト側の行が数えている **[2026-08-27] 証跡から2件落とした** —— `../simplememo-api/src/cancel-flow.ts` と その検査は**存在しない**（解約フローの実装は iOS 側の CancelFlowManager.swift / CancelFlowViewController.swift で、API 側に同名のものは無い）。**CIが `../` の実在を見ていなかったので、誰にも気づかれずに残っていた。**見える場所（3リポジトリが揃ったセッション）では見るようにした。"
    },
    {
      "area": "⑨ マネタイズ",
      "task": "課金失敗の回復",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/SimpleMemo/SubscriptionRenewalState.swift",
        "../simplememo-ios/SimpleMemo/SettingsViewController.swift",
        "../simplememo-ios/SimpleMemoTests/SubscriptionLogicTests.swift",
        "../simplememo-ios/docs/implementation/billing-recovery-settings.md",
        "../simplememo-api/src/billing-recovery-monitor.ts",
        "../simplememo-api/test/billing-recovery-readiness.integration.test.ts",
        "../simplememo-api/test/billing-recovery-monitor.test.ts",
        "docs/billing-recovery-tested-readiness-20260913.md",
        "data/billing-recovery-readiness-20260913.json"
      ],
      "note": "StoreKit側の失敗イベントを受ける経路が未実装。**[2026-08-26] 検知の側だけ配線が入った** ——Subscription State Report の `State Metric` に Billing Retry / Grace Period が入るので、asc_subscription.rb がそれを課金失敗として拾う（別行「課金失敗・解約の観測」）。**この行は nobody のまま。**数えているのは『回復させたか』であって『気づけるか』ではない。回復（アプリ内での告知・支払い方法の更新導線）は1つも実装していない。**気づけることを回復と数えない。**\n\n2026-09-08訂正: 「回復導線は1つも実装していない」は過去の状態。iOS PR387（merge d3dab4406e95fd0352818685810e880bc620a6fd、2026-09-07）で、署名検証済みの請求再試行・猶予期間を読み、設定の購入提案を支払い情報更新への案内に置き換える処理が実装された。Appleの支払い設定を利用者のタップで開き、画面復帰時に再取得する。現行mainの処理と実装文書を確認済み。既存購読・未検証状態の混在では表示を抑制し、権利付与や価格は変更しない。実装を繰り返す必要はないが、実際の請求問題からの回復は未確認のためexecutor=nobodyを維持する。\n\n[2026-09-13 完了条件変更] 返金と同様のテスト済み運用準備を提案し、オーナーが「スコアすぐあがるなら進めて」と指定。この1業務に限り、既存支払い案内の状態判定・設定セルの遷移テスト、検証済み通知のHTTP受信→実D1→重複抑止→回復監視テスト、配信済みの毎時監視の自然発火と既存フォローアップへの接続を完了条件にした。StoreKit状態はfixtureであり、Apple支払い画面での本人操作・Sandbox実決済・本番の実回復は未確認のまま別に保持する。新たな購入や請求失敗を作らず、回復通知も案内UIの効果に帰属させない。後日の本番初回回復で二重加点しない。変更直前161/177=90.960452%、変更後162/178=91.011236%、増分は約0.050784ポイント。全社月次予算の別セッションによる加点は維持し、本変更に帰属させない。",
      "since": "2026-09",
      "acceptance_basis": "test_verified_readiness_and_active_production_monitoring",
      "production_billing_recovery_observed_at": null
    },
    {
      "area": "⑨ マネタイズ",
      "task": "返金の検出（Get Refund History）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/apple-asn.ts",
        "../simplememo-api/src/apple-jws.ts",
        "../simplememo-api/src/der.ts",
        "../simplememo-api/test/fixtures/asc-test-notification.jws",
        "../simplememo-ios/data/asc-server-api.json",
        "../simplememo-ios/scripts/asc_refund_probe.rb",
        "../simplememo-ios/scripts/lib/asc_api.rb",
        "docs/subscription-observation-evidence-20260910.md",
        "docs/refund-history-observation-20260913.md",
        "../simplememo-api/src/refund-monitor.ts",
        "../simplememo-api/test/refund-readiness.integration.test.ts",
        "docs/refund-tested-readiness-20260913.md",
        "data/refund-readiness-20260913.json"
      ],
      "note": "**旧行から切り出した。**旧行は「返金・不正課金・チャージバック対応」で、検出・応答・意見表明が1行に入っていた。混ぜると、どれか1つができた時点で行が動く。 これは**観測だけ**で、外に何も出ない可逆な操作 —— 権限表の非対称でいえばAI側。 **[2026-08-27 実測 — この2つは「未確認」ではなくなった]** `POST /inApps/v1/notifications/test` を1回叩いた（../simplememo-ios/data/asc-server-api.json・run 33029719938）。HTTP 404 / ServerNotificationURLNotFound。読みは2つ: **(1) 鍵は通る。**いまの App Store Connect API の鍵で App Store Server API を叩ける（JWT に `bid` クレームを足すだけ。別の In-App Purchase 鍵は要らなかった）—— **「別の鍵が要る」と推測で書かなくてよかった。** **(2) 通知URLが設定されていない。**したがって CONSUMPTION_REQUEST はどこにも届いていない。 残っているのは実装だけ: `GET /inApps/v2/refund/lookup/{transactionId}` は**取引IDを要求する**ので、まず取引を1つ手に入れる経路が要る（Get Transaction History / 通知）。**そこは叩いていないので、取引IDの出どころが実在するかはまだ書かない。**\n\n**[2026-08-27 追記 — 取引IDの出どころは、探さなくてよかった]** 上で「取引IDの出どころが実在するかはまだ書かない」と保留していた点が解けた。Apple の notificationType の一覧を取って確かめたところ、返金は**通知として押されてくる**: `REFUND`（返金した）／`REFUND_DECLINED`（アプリ内の要求を却下した）／`REFUND_REVERSED`（争議で返金を取り消した）。つまり `refund/lookup` に渡す取引IDを別経路で先に手に入れる必要は無く、**通知が運んでくる。** \n\n同日、その通知を受ける側が揃った: 受け口（simplememo-api の `/webhooks/apple-asn`）、通知URLの設定（Apple の実配信が `first_attempt_result: SUCCESS`）、そして **signedPayload の検証器**（`src/apple-jws.ts`）。検証器は**Apple が実際に署名した TEST 通知**で通ることを確かめてある。信頼の起点は通知に入っていた root ではなく、Apple の公開ページからランナーが取った実物（`data/apple-root-pin.json`・583 bytes / sha256 63343abf…。両者はバイト単位で一致した）。\n\n**残っているのは、受け口が検証器を呼ぶ配線と、通知を残す部分。**後者は simplememo-api の保持台帳（`data/data-retention.json`）に何をどれだけ持つかを書いてからでないと着手しない —— 受け口はいま**意図的に env を取らない**形で、書き込む手段そのものを持っていない。\n\n[2026-09-10 実観測] 本番D1のapple_refund_eventsを型・環境別に読み取り集計し、保存済み通知が空であることとrows_written=0を確認した。受信・保存経路の再実装は不要。実際の返金通知の受信証拠は得られていないためexecutorはnobodyのまま。\n\n[2026-09-13 追加実観測] 本番の保持済み通知とApple側の返金通知履歴を読み取り、観測された更新取引からのGet Refund Historyを期間分割して完了した。取得元のApple署名・アプリ・環境・商品・対象期間と各照会の完了を検証したが、返金取引は返らなかった。観測対象に限った結果であり、全顧客の返金不存在や実際の返金検出とはしない。件数上限を超えた場合の診断をiOS PR502で区別し、上限は維持。executorと加点は変更しない。\n\n[2026-09-13 完了条件変更] オーナーが「テストで運用準備を完了し、本番の初回検出は自動監視に任せる。テスト完了時にスコアをあげる」と明示指定した。この1業務に限り、検出・記録・重複防止・失敗回復のテスト、Apple実署名と本番TEST通知の疎通、本番の毎時監視の稼働確認を完了条件にする。ローカル返金fixtureとApple-issued Sandbox返金を混同せず、本番の初回返金検出は未観測として別に保持する。後日の実返金検出で二重加点しない。変更前の本番実例必須基準では159/176=90.340909%である。",
      "since": "2026-09",
      "acceptance_basis": "test_verified_readiness_and_active_production_monitoring",
      "production_refund_observed_at": null
    },
    {
      "area": "⑨ マネタイズ",
      "task": "返金要求への消費情報の応答（CONSUMPTION_REQUEST）",
      "executor": "intentional_no",
      "evidence": [
        "../simplememo-api/src/apple-asn.ts",
        "../simplememo-api/src/apple-jws.ts",
        "../simplememo-api/data/apple-root-pin.json",
        "../simplememo-ios/data/asc-server-api.json",
        "../simplememo-ios/scripts/asc_refund_probe.rb"
      ],
      "note": "**旧行の「上限額を決めない限り自動側へ置けない」という前提は誤りだった。**2026-08-27 に Apple のドキュメントを取って確かめた —— **返金を発行するエンドポイントが存在しない。**あるのは Get Refund History（履歴）、Refund lookup（照会）、Send Consumption Information（消費情報の送信）の3つで、**機械が返金できないので上限額は何も止めない。** 実在するのはこちら: 顧客が返金を要求すると Apple が CONSUMPTION_REQUEST を送り、開発者は `PUT /inApps/v2/transactions/consumption/{transactionId}` で応える。**期限は「受信から12時間以内」**（同エンドポイントのドキュメントに明記）。応えなければ Apple はこちらのデータ無しで判断する。**12時間は人が確実に守れる窓ではない**（個人開発・時差・睡眠）。だから自動化の利得は「速さ」ではなく**「窓を落とさないこと」**にある。 **[2026-08-27 実測 — この2つは「未確認」ではなくなった]** `POST /inApps/v1/notifications/test` を1回叩いた（../simplememo-ios/data/asc-server-api.json・run 33029719938）。HTTP 404 / ServerNotificationURLNotFound。読みは2つ: **(1) 鍵は通る。**いまの App Store Connect API の鍵で App Store Server API を叩ける（JWT に `bid` クレームを足すだけ。別の In-App Purchase 鍵は要らなかった）—— **「別の鍵が要る」と推測で書かなくてよかった。** **(2) 通知URLが設定されていない。**したがって CONSUMPTION_REQUEST はどこにも届いていない。 **通知URLを設定する経路が機械には無い。**App Store Connect API の索引（webhooks は BUILD_UPLOAD_STATE_UPDATED など**ビルド・審査の事象だけ**で、CONSUMPTION_REQUEST は入っていない）と App Store Server API の索引の**両方を数えた**が、通知URLを設定する面はどちらにも無かった。**人が App Store Connect の画面で1回設定する**しかない。設定さえ済めば、受け口も応答も機械側で完結する。 受け口自体もまだ無い（simplememo-api の /v1/* にASC通知の口は1本も無い）。 **述語について**: 待ちが解けたかどうかは、隣の実測台帳（../simplememo-ios/data/asc-server-api.json）を probe が書き直したときに分かる。**このリポジトリのCIには隣が無いので、CIからは常に「まだ待っている」と読める** —— 3リポジトリの揃ったセッションでだけ「もう届いている」と鳴る。散文で「未設定」と書いておくよりはましだが、**片側でしか鳴らない述語であることは承知の上**（隣が無ければ満たされない側に倒れるので、見落とす方向ではなく待ち続ける方向に外れる）。\n\n**[2026-08-27 追記 — 待っていた設定は済んだ。そして本当の門は別にあった]** オーナーが App Store Connect で通知URLを設定した（`https://api.simplememofast.com/webhooks/apple-asn`）。実測で裏が取れている: `POST /inApps/v1/notifications/test` が HTTP 200、`notification_url_configured: true`、そして **Apple の実配信が `first_attempt_result: SUCCESS`**（../simplememo-ios/data/asc-server-api.json・run 33067382043）。受け口も検証器も揃い、**Apple が実際に署名した通知を検証できることまで確かめた。**\n\n**それでもこの行は機械に渡せない。**Send Consumption Information のドキュメントを取って読んだ:\n\n  「If the customer provided consent, respond by calling this API … **If not, don't respond to the CONSUMPTION_REQUEST notification.**」\n  「The App Store server **rejects requests that have a customerConsented value other than `true`** by returning an HTTP 400 error with an InvalidCustomerConsentedError」\n\n**`customerConsented: false` は「正直な応答」ではなく、400 で弾かれる。**応答するには**顧客がアプリ内で明示的に opt-in している**必要があり、Apple は「いつでも撤回できること」「撤回の方法を示すこと」「privacy label に書くこと」まで要求している。SimpleMemo にはその同意フローが無い。\n\n**ここで止まるのは実装が足りないからではない。**「顧客の利用状況を Apple に渡して、その顧客の返金要求に反論してよいか」を顧客に opt-in で問う、という製品の判断が先にある。プロダクトの立て付け（何も所有しない・整理させない）と正面から擦れる話で、**しかも現時点の実績は購入1件**（../simplememo-ios/data/revenue/series.json）。得られるものが小さく、聞くこと自体に costs がある。**だから機械の側で既成事実にしない。**\n\n（前の版はここを external_credential と書いていた。設定が済んだのでその塞ぎは外れたが、外れた先に出てきたのは実装ではなく境界だった。**塞ぎが1つ外れても、その先が自動側とは限らない。**）\n\n**[2026-08-27 決定 — オーナー判断「作らない」]** 同意フローは作らない。したがってこの行は**意図的にやらない**側へ移す。\n\n**放置ではなく、仕様どおりの振る舞い。**Apple は「同意が無ければ CONSUMPTION_REQUEST に応答するな」と明示しており、同意フローを作らない以上、**応答しないことが正しい。**受け口・署名検証は動いたまま残る（通知は受け取って検証し、CONSUMPTION_REQUEST だと分かった時点で応答せずに終える）。\n\n判断の材料: (1) 返金申請が発生する頻度が極めて低い規模（取得できている売上は1日分・購入1件）。(2) **正直に説明すればほぼ誰も許可しない**トグルで、許可を得るために説明を曖昧にするのは、やってはいけないことそのもの。既定ONも不可（Apple 自身が \"only if the customer consented\" と書いている）。(3) 顧客に「返金の話」を先に持ち出すUIが増え、VISION の「何も整理させない」と逆行する。\n\n**⚠ この決定で総合自動化率は 65.3% → 65.7% へ上がる**（分母から1件外れるため）。**やめたことで数字が良くなる**という形なので、動いたことを台帳と配信稿の両方に書いてある。下がった回を書くのと同じ理由で、上がった回も書く。\n\n**取り消せる判断。**作ると決めた日に効く配線（受け口・検証・応答の組み立て・`lookupConsumptionConsent()`）は全部入っているので、残作業はアプリ側の同意UIと privacy label だけ。"
    },
    {
      "area": "⑨ マネタイズ",
      "task": "返金の可否についてAppleに意見を出す（refundPreference）",
      "executor": "intentional_no",
      "evidence": [
        "docs/automation-scope-review-20260913.md"
      ],
      "note": "**ここが本当の境界。**ConsumptionRequest の必須欄は customerConsented / deliveryStatus / sampleContentProvided の3つで、**どれも事実**（同意の有無・配信できたか・購入前に無料で試せたか）。SimpleMemo は無料枠があるので sampleContentProvided は定数に近い。**事実だけで有効な応答が作れる。** 判断が入るのは `refundPreference` **1欄だけ**で、しかも**必須ではない。**値は DECLINE / GRANT_FULL / GRANT_PRORATED の3つ。Apple は「your refund preference is one of a variety of factors that the App Store uses to inform its refund decisions」と書いている。 つまり DECLINE を出すことは、**機械が「この客に返金しないでほしい」とAppleに言う**ということ。定型文でレビューに返すのとは性質が違う —— 相手は返金を求めている個人で、こちらの一言が不利に働きうる。 **設計としては、この欄を省いて応答できる。**期限内に事実を出す（＝窓を落とさない）ことと、可否に意見を言うことは分けられる。**分けられるものを一緒に自動化しない。** 自動化するなら Level を明示すること（返信のゲートと同じ）。既定は「refundPreference を送らない」\n\n[2026-09-13 事業スコープ決定] 既存業務147で消費情報応答と同意フローを作らないと決定済み。任意の返金意見送信も現在の製品方針に採用しない。 オーナーが妥当な業務の対象外化を明示承認。AI実行は増えていない。旧分類・再開条件はscope_exclusionに保存。",
      "scope_exclusion": {
        "decided_on": "2026-09-13",
        "previous_executor": "nobody",
        "reason": "既存業務147で消費情報応答と同意フローを作らないと決定済み。任意の返金意見送信も現在の製品方針に採用しない。",
        "reactivate_when": "消費情報応答を行う製品方針に変更した時点で、147との関係を含め必要性を再評価する。",
        "evidence": "docs/automation-scope-review-20260913.md",
        "previous_blocker": "policy_boundary",
        "previous_unblocked_by": "**機械が「返金しないでほしい」と言ってよいか。**事実だけの応答（refundPreference 無し）はこの行の外で、そちらは境界ではなく実装",
        "previous_authority_absent": "表に領域が無い。**機械が「返金しないでほしい」と言ってよいか**という問いで、事実だけの応答（refundPreference 無し）はこの行の外"
      }
    },
    {
      "area": "⑨ マネタイズ",
      "task": "短期CVRよりLTVと信頼を守る制約",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/docs/VISION.md",
        "scripts/check-prd.mjs"
      ],
      "note": "VISION §0「AIを前面に出さない」・§9「所有しない」が実質この制約。§13の6問がゲート **[2026-08-27] §13の6問を実際に検査しているのは check-prd.mjs。**VISION は制約の本文で、読むだけでは1件も止まらない"
    },
    {
      "area": "⑨ マネタイズ",
      "task": "価格の変更",
      "executor": "human_only",
      "evidence": [
        "data/authority-matrix.json"
      ],
      "note": "AIは提案もしない（不可逆・既存契約者への影響が読めない）",
      "blocker": "policy_boundary",
      "unblocked_by": "不可逆・既存契約者に影響",
      "authority": {
        "domain": "価格・プラン・無料枠の変更",
        "human_only": "すべて"
      }
    },
    {
      "area": "⑨ マネタイズ",
      "task": "課金失敗・解約の観測（内訳の取得と読み）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/asc_subscription.rb",
        "../simplememo-ios/scripts/asc_analytics.rb",
        "../simplememo-ios/.github/workflows/asc-analytics.yml"
      ],
      "note": "2026-08-26実装。取得（日次・GETのみ）から読みまで人の承認を挟まない。ゲートは3つで、**どれも「言い過ぎ」を止める向き**に置いてある。(1) 読めない理由を1語に潰さず7状態に分け、**数を出してよいのは readable のときだけ** (2) 分母が 20 に届かないうちは率を出さない（解約1件から解約率100%を作らない。simplememo-api の CLAUDE.md「単日の率では何も決めない」と同じ下限） (3) 知らない State Metric を健全側に寄せず unclassified として名前ごと残す ——**寄せると Apple が新しい失敗状態を足した日に課金失敗が消える。**内部矛盾（readable なのに値が無い／分母不足で率がある）は exit 1 で日次を赤にする。\n\n**この行が数えているのは『毎日走ること』であって『値が降りていること』ではない。**2026-08-26 時点の読みは 0/3（手元の取得結果は内訳を持つ前の版）。self-test 28件。\n\n**読みは非公開リポジトリ側に置いた。**一度サイト側（growth/scripts/）に書いたが、simplememofast/simplememo は GitHub 上で公開されており（api.github.com が private: false）、契約者が1桁のいま解約・課金失敗の件数を公開リポジトリへ日次で積むのは「広げる」方向の変更になる。加えてあちらの CI からは隣のリポジトリが見えず**日次では動かない。**動かない場所に検査を置かない"
    },
    {
      "area": "⑩ AgentOps・ガバナンス",
      "task": "実行の完全記録（主系）",
      "executor": "ai_executes_gated",
      "evidence": [
        ".github/workflows/obsidian-autopilot.yml"
      ],
      "note": "Actionsのrunログは全部読める"
    },
    {
      "area": "⑩ AgentOps・ガバナンス",
      "task": "実行の完全記録（副系）",
      "executor": "ai_executes_gated",
      "evidence": [
        "docs/obsidian/AUTOPILOT_RUNBOOK.md",
        "docs/routine-snapshot-setup.md",
        "scripts/check-routine-runs.mjs",
        "data/routine-runs.json",
        ".github/workflows/seo-check.yml",
        "scripts/codex-routine-observer.py",
        "scripts/routine-observer-local.py",
        "docs/codex-routine-observation.md",
        "docs/execution-records-and-rd-20260908.md"
      ],
      "$previous_note": "スケジュール起動セッションのログが外部から読めない。構造的に不可\n\n**[2026-08-28] 「構造的に不可」は半分だけ正しかった。**セッションの中身（transcript）は依然として外から読めないが、**走ったかどうかは読める** —— Routines API の `last_run` が status / fired_at / finished_at / session_id を返す。**読む側を一度も試さずに不能と書いていた。**\n\n**読んだ瞬間に4件見つかった。**副系A（07:30）と副系B（08:30）が 2026-08-25 を最後に停止したまま2日以上、週次2本（SEO Weekly / マーケデータ）が 08-24 に FAILED のまま次の発火は 08-31。**どれも次の発火まで誰も気づかない形だった。**これが「完全な記録が無い」ということそのもの。\n\n**主系と副系で、記録の完結の仕方が違う。**主系（Actions）は run を全部列挙できるので記録が完結する。副系は**セッションが自分で書いたときだけ**行が残る（autopilot-runs.json の source:session）ので、**書かずに死んだ回はどこにも現れない。**自己申告だけでは完全にならない。\n\n実装は scripts/check-routine-runs.mjs（写しの鮮度・列挙の網羅・ラチェット）。list_triggers はCIから叩けないので、セッションが data/routine-runs.json へ写しを置きCIが検査する（ASCのレポートと同じ形）。**executor はまだ動かさない** —— 写しを取り直す経路がまだ人の手で、そこが自動になって初めて『記録が完結している』と言える。鮮度検査が3日で赤くなるので放置はできない\n\n**[2026-08-28 追記] 残る未検証2つのうち1つを叩いた。決まらなかった。**現に動いている副系（`trig_01ESF9AHax6buS9X1pdFv657`・Obsidian再試行 v3）の最新セッションを `get_session` で読んだ。\n\n**分かったこと** —— `session_context.sources` にリポジトリが入り、`outcomes` に `claude/obsidian-auto-20260828` が出ている（＝**この経路は sources を持ち、ブランチも作れている**）。tags は `routine:agent-minted`。\n\n**分からなかったこと** —— `get_session` の応答に `allowed_tools` が**含まれていない**ので、**このセッションが `mcp__*` を持つかは読めなかった。**\n\n**「欄が無い」を「MCPが無い」と読まない。**朝の記録が「`allowed_tools` に `mcp__*` は1つも無い」と書けたのは、`create_trigger` で自分が作った Routine の応答に**その欄が在った**から。**欄そのものが返らないケースと同じにしない。**\n\n確かめる手は残っている（この副系の prompt に `list_triggers` を1回呼ばせて結果を書かせる）が、**日次で動いている本番ジョブの prompt を書き換える操作なので、オーナーに聞いてから。**自己バインド側は未着手のまま。\n\n**[2026-08-28 夕・実測] 対照が取れた。「副系は MCP を持てない」は一般化しすぎだった。**\n\n**持たない側（実挙動で確認）** —— このCCRセッションが `create_trigger` で作った routine（`environment_id` を明示）を `fire_trigger` で1回走らせた。**17.5秒で SUCCEEDED、ブランチ0、$0.29**（`cse_01MWDUzNh1Df8EyF7oNEz2Ws`）。prompt は「`list_triggers` が呼べたら写しを取り直してPRを出す／呼べなければ報告だけして終われ」で、**Step 2 に到達していない**（`claude/routine-snapshot-20260828` は作られていない）。作成時に警告が返っており、そこに理由が書いてある —— 「Connectors on triggers created via this tool are limited to those the calling session itself holds; **this call had none to pass through**」。**このセッション自身は `mcp__*` を持っているのに、渡せる grant としては持っていない。**確認後この routine は削除した。\n\n**持つ側（実測）** —— 同じ日、`ccr-0920`（`trig_01ESF9AHax6buS9X1pdFv657`・オーナーのセッションが作った routine）のスケジュールセッションが **PR #696 を実際に作っている。**根拠はPR本文のフッタが `session_01UuFE2rHRSKuqKLeoAuGFQg` を名指ししていること（`get_session` で読んだのと同じセッション）と、本文が「§0の(a)〜(e)で確認済み」と書いていること —— (e) は prompt が**GitHub MCP の `actions_list`** と定義している手順。この環境に `gh` CLI は無く、PR作成は GitHub MCP を通る。\n\n**したがって差は「副系かどうか」ではなく「どのセッションが routine を作ったか」。**CCRセッションが作った routine には connector が渡らず、オーナーのセッションが作った routine には渡っている。\n\n**それでも ⑩ は閉じない。**分かったのは **GitHub MCP** を持つことで、要るのは `claude-code-remote` の `list_triggers`。**別のサーバなので片方から他方を推定しない**（このファイルが 08-26 と 08-27 に続けてやった「辻褄が合うことを証明に使う」がまさにこれ）。\n\n**確かめ方は仕込んだ。**本番 prompt は書き換えていない —— あの prompt 自身が「`docs/obsidian/AUTOPILOT_RUNBOOK.md`（mainの最新版）が優先します」と書いているので、**Runbook に §0-3 として一時的な確認を足した**（2026-08-29 まで・記事の作業に影響させない・失敗しても run を落とさない）。9,358字の prompt を打ち直す経路より、**PRでレビューでき git で戻せる**ほうを選んだ。\n\n次の発火は 2026-08-29T00:20Z。報告に `ROUTINE_MCP_PROBE:` の1行が出たら、この行を更新して Runbook の §0-3 を削除する。\n\n**「SUCCEEDED」がまた何も言っていない。**上の使い捨て routine は 17.5秒で成功扱いで終わり、**やるはずのことは1つも起きていない。**この台帳が `intentional_stops` に書いたのと同じ形が、同じ日にもう一度出た。\n\n**[2026-08-31] 仕込んだ確認は走っていない。理由は2つあって、1つ目はこちらの手落ち。**\n\n**(1) §0-3 が main に無い。**prompt は「`docs/obsidian/AUTOPILOT_RUNBOOK.md`（**mainの最新版**）が優先します」と書いていて、こちらはその一文を引用したうえで §0-3 を `claude/score-improvement-nug323` に置いたまま**PRを作らなかった。**日次セッションが読むのは main なので、**一度も届いていない。**「Runbook に置けば伝わる」は、mainに入って初めて成り立つ。\n\n**(2) そもそも日次が落ちている。**ccr-0920 は 2026-08-31 に FAILED（13秒）。原因は週次利用枠の枯渇で、同日 obsidian-community と SEO Weekly も同じ形で落ちている（`data/routine-runs.json` の open_findings 参照）。**仮に §0-3 が main に入っていても、この回は走らなかった。**\n\n**したがって「副系のセッションが `claude-code-remote` の MCP を持つか」は未検証のまま。**08-28 に取れた対照（CCRセッション製の routine は持たない／ccr-0920 は GitHub MCP を持つ）はそのまま有効で、**動いていないのは確認の経路のほう。**\n\n**[2026-09-01] 確認は走ったが、答えたのが違う経路だった。**§0-3 は #742 で main に入り（2026-08-31T23:50Z）、枠のリセット後の 09-01 に主系・副系とも動いた。**ところが `ROUTINE_MCP_PROBE:` を報告したのは主系（Actions）で、内容は `unavailable 主系Actions環境にCCRのMCPが無い`。**\n\n**これは正しい観測だが、この行が聞きたい問いではない。**Actions のランナーに CCR の MCP が無いのは自明で、知りたいのは**スケジュール起動された CCR セッション**が持つかどうか。**節を Runbook に置いたので両方の経路が読んだ** —— 経路を限らなかったこちらの設計ミス。同じ変更で「実行するのは CCR 経路だけ」と限定した。\n\n**副系（ccr-0920）は 09-01T00:20:49Z に SUCCEEDED で走ったが、主系が当日ロックを先に取っていたためスキップした**（70秒・$0.42・`cse_012o7p4daBaPPPRwsuRdpZtT`）。**スキップ回は LOG を書かないので、リポジトリには何も残らない。**報告自体はセッションの中にあるが、**成功したセッションの `post_turn_summary` は `get_session` から返らない**（失敗したセッションでは返る。08-31 の3本がそれ）。\n\n**したがって答えが届くのは、ccr-0920 が実際にその日の仕事をした回** ——つまり主系が当日ロックを取らなかった日。**それまでこの行は動かない。**待ち方が1つ増えたのであって、2026-08-28 に取れた対照（CCRセッション製の routine は持たない／ccr-0920 は GitHub MCP を持つ）は変わっていない。",
      "$previous_blocker": "not_started",
      "$previous_unlock": "impl_routine_snapshot",
      "$previous_unblocked_by": "**2026-08-28 に「読めない」が崩れた。**Routines API の last_run で発火・成否・時刻が外から読める。残るのは**写しを定期的に取り直す経路**（list_triggers はCIから叩けないので、セッションが取る）。取り直しが自動になれば、記録は主系と同じ意味で完結する\n\n**[2026-08-28 夕・実際に作って回して確かめた] 自動化は Routine 側の壁で止まる。**`create_trigger` で日次 Routine（`trig_01Gb9SYzhT7C7YjAvz5dNzD1`）を作り、`fire_trigger` で1回走らせた。結果:\n\n- **`environment_id` は引き継がれた。**明示すれば `env_01RmhZUdCQoTVYsGM6Ly45oP` が `job_config.ccr` に入る。**`docs/reaching-85-audit-2026-08-28.md` の「sources も MCP connector も付かず」のうち、sources 側は環境IDを渡さなかった場合の話だった。**\n- **`mcp__*` は引き継がれない。**作成時に警告が返る（「this trigger stores no MCP connectors, so the sessions it fires will run without connector tools」）。`session_context.allowed_tools` にも `mcp__*` は1つも無い。\n- 実走（`cse_015iYEg3GrcfQ2A55jv9aZD1`・3分35秒・$0.83）は `SUCCEEDED` で終わり、**ブランチもPRも作られなかった** —— 「list_triggers が呼べなければ何も書かずに報告して終われ」と指示した経路と一致する。\n\n**Routine は日次で失敗し続けて未対応枠を食うので削除した。**残る未検証の道は1つ、**claude.ai の Routines UI から作った Routine なら `mcp__*` を持てるか**（作成時の警告文が案内している経路）。これはオーナーの画面操作なので、`impl_routine_snapshot` は実装ではなく owner_input へ移した。**「不能」とは書かない** —— 叩いていない面が1つ残っている\n\n**[2026-08-28 夕・経路2も叩いた。閉じた。]**オーナーが claude.ai の Routines UI から実際に作り（`trig_01TixKQ5Sovfjfn8rRVQCrYf`）、1回走らせた。**ブランチ0・PR0**（05:42:56Z→05:46:32Z・3分36秒・$2.46）。原因は connector ではなくリポジトリのほうだった —— **編集画面にリポジトリを指定する欄が無い**（名前 / 手順 / 頻度 / 権限の4つだけ）。発火したのは Cowork のセッションで、`environment_id` は汎用値 `env_011111111111111111111117`、tags は `cowork-remote / cowork-scheduled`、`folders_state: FOLDERS_STATE_NONE`、sources 無し。**`simplememo` に辿り着けない。**Routine は削除せず、名前に理由を書いて停止した（`data/routine-runs.json` が求めている形に合わせた）。\n\n**それでも `structural` へは落とさない。叩いていない面が2つある。**(1) **既存の副系Routineのセッションが `mcp__*` を持つか** —— `Obsidianオートパイロット再試行 v3` などは `job_config.ccr.environment_id` に副系の env を持ち、現にリポジトリへ到達してPRを作っている。UIで作ったものとは作られ方が違う。ただし確かめるには本番の記事パイプラインを1回走らせることになる（前回25分）ので、ついでに確かめられる機会を待つほうが安い。(2) **自己バインドの Routine**（`bound_session: true`・`カナリア48時間後` がこの形）—— 既存セッションへ配信されるので、そのセッションが持つMCPがそのまま使える。\n\n**2回とも `last_run: SUCCEEDED` で終わっている。**できないセッションは「できないので何も書かずに終わる」で成功になる。**判定はブランチ・PR・observed_at の3つで行うこと。** ／ **[2026-09-01] 『Routineはリポジトリを持てない』が崩れた。**13本の `session_context.sources` を実測したら4本が repo を持っている（副系A・副系B・ccr-0920・SEO Weekly）。止まっていた routine は `sources: null` で作られていただけ。**経路は作れる。**残る未確認はスケジュール起動セッションが `claude-code-remote` MCP を持つかの1点（Runbook の ROUTINE_MCP_PROBE）\n\n**[2026-09-05] 待っても届かない形になっている（実測）。**この行を開けるための確認（Runbook §0-3）を実行できる唯一の経路 `ccr-0920` は、`list_triggers` で見ると **2026-09-05T00:20:16Z に発火して 12秒で FAILED**。Runbook を読む前に死んでいる。理由は `data/routine-runs.json` の open_findings にある —— **session limit。主系と利用枠を共有しているので、副系は独立した容量の代替になっていない。**\n\nしかも配達条件が構造的に不利で、答えが残るのは **主系が当日ロックを取らなかった日**だけ。その日は枠が枯れている日でもあるので、**答えが要る条件と答えられない条件が同じ。**日付での延長を3回（08-29 → 08-31 → 09-05）試して3回とも空振りしたので、**期限は日付ではなく条件で置き直した。**\n\n**写しそのものは在る**（`data/routine-runs.json`・0.0日前）が、**取り直しているのは人が起こしたセッション。**自動になっていないので、この行は `nobody` のままが正しい。",
      "since": "2026-09",
      "note": "2026-09-08: 移管後の副系を含む登録Codex予約2件について、既存の毎時観測が実行3件・6ターンを取得し、06:58 UTCの自然起動で観測PR #1148を作成した。サービス実行23回目・終了0と照合し、手動発火や起動環境の偽装は行っていない。初回失敗1件と後続の正常終了を分け、原ログのハッシュ・時刻・ツール呼出/結果件数を残す。原ログは非公開のまま。既存Claude19登録の停止・失敗履歴も維持する。取得・公開の証拠は docs/execution-records-and-rd-20260908.md。"
    },
    {
      "area": "⑩ AgentOps・ガバナンス",
      "task": "誰が何を変更したかの監査ログ",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/autopilot-runs.json"
      ],
      "note": "経路・結果・介入は機械可読。判断の根拠はまだ散文"
    },
    {
      "area": "⑩ AgentOps・ガバナンス",
      "task": "最小権限（AIに与えない権限の明文化）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/.github/workflows/claude.yml",
        "scripts/check-authority.mjs"
      ],
      "note": "actions:write 非付与。CIが実際に検出する"
    },
    {
      "area": "⑩ AgentOps・ガバナンス",
      "task": "Prompt Injection・Tool Poisoning対策",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/injection-surface.json",
        "scripts/check-injection-surface.mjs",
        ".github/workflows/seo-check.yml",
        "../simplememo-ios/.github/workflows/release-command.yml"
      ],
      "note": "2026-08-22実装。外部文字列が入る口6件を台帳にし、口ごとに緩和策と**残存リスク**を必須にした（残存リスクが空＝考えていない、として落とす）。ワークフローの run: に ${{ github.event.* }} が直接埋まっていないかを走査する（env: 経由は安全なので除外）。自己検証で、脆弱なワークフローを差し込むと検出し、env: 経由では誤検出しないことを確認した。残る弱さ: **検査できるのは口の棚卸しとシェル注入だけ**で、モデルが読んだ本文に従ってしまう経路そのものは検査していない",
      "since": "2026-08"
    },
    {
      "area": "⑩ AgentOps・ガバナンス",
      "task": "AIへの送信内容のredact",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/qa/build-ai-triage-bundle.sh"
      ],
      "note": "PII無し・サイズ上限つき要約のみ"
    },
    {
      "area": "⑩ AgentOps・ガバナンス",
      "task": "エージェント別 Kill Switch",
      "executor": "ai_executes_gated",
      "evidence": [
        ".github/workflows/obsidian-autopilot.yml",
        "data/emergency-stop.json",
        "scripts/check-emergency-stop.mjs",
        "scripts/autopilot-gate.mjs",
        "scripts/autopilot-selfheal.mjs",
        "scripts/autopilot-drill.mjs"
      ],
      "note": "2026-08-22実装。経路6件（主系・副系2・代走・監査・ASC）を個別に止められる。実行判定が AGENT_STOPPED を返し、**全体停止は常にこれより強い**（両方立っているとき経路側が先に出たら落ちる）。主系ワークフローも全体と agents.actions の両方を見る。止めるのはAIができる（`--contain` / `--trip`、理由は escalation-rules の trigger に限定）が、**解除の関数はスクリプトに存在せず、追加すると検査が落ちる。**修理上限に達した経路は着手前に落ちる（--contain --dry-run）。残る弱さ: **本番で1回も止めていない**（止まることを確かめていない停止機構は、無いのと同じに近い）",
      "since": "2026-08"
    },
    {
      "area": "⑩ AgentOps・ガバナンス",
      "task": "失敗理由とバックアップ切替の観測",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/autopilot-runs.json",
        "scripts/autopilot-runs.mjs"
      ],
      "note": "by_route・primary_ever_shipped・failure_class"
    },
    {
      "area": "⑩ AgentOps・ガバナンス",
      "task": "基盤故障の自己修復と、その歯止め",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/autopilot-selfheal.mjs",
        "scripts/check-authority.mjs"
      ],
      "note": "検証の弱体化・権限の拡大をCIが実検出"
    },
    {
      "area": "⑩ AgentOps・ガバナンス",
      "task": "バックアップ切替の演習",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/autopilot-drill.mjs"
      ],
      "note": "2026-08-22実装。判定の論理を15シナリオで検証。**実際のネットワーク・認証の挙動は証明しない**"
    },
    {
      "area": "⑩ AgentOps・ガバナンス",
      "task": "自律システムとは別系統の監査AI",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/audit-charter.json",
        "data/audit-findings.json",
        "scripts/check-audit-independence.mjs",
        "data/model-routing.json"
      ],
      "note": "2026-08-22実装。**監査の中身ではなく独立を機械が守る**：①憲章と所見を自己修復レーンが書き換えられない ②監査は repair と別モデル ③所見は追記のみ（連番が飛ぶと落ちる）。監査AIは何も直さない（直す権限を持たせると「直したことにして所見を閉じる」が最短経路になる）。**まだ一度も走らせていない。**残る弱点（監査が article と同じモデル）も憲章に明記",
      "since": "2026-08"
    },
    {
      "area": "⑩ AgentOps・ガバナンス",
      "task": "認証切れ・モデル障害・API障害の演習",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/autopilot-gate.mjs",
        "scripts/autopilot-drill.mjs"
      ],
      "note": "2026-08-22実装。判定に4つの故障軸（資格情報の拒否・モデル全滅/縮退・GitHub API到達不能・egress遮断）を足し、26シナリオで固定。**「秘密鍵が無い」と「拒否された」を別コードにした** — 混ぜると期限切れが毎日「設計どおりのスキップ」として黙殺される。**本番を落とす本物の演習ではない**（判定の論理だけ）",
      "since": "2026-08"
    },
    {
      "area": "⑩ AgentOps・ガバナンス",
      "task": "判断→実行→結果→次の判断を結ぶ運転記憶",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/operating-memory.json",
        "scripts/check-operating-memory.mjs",
        ".github/workflows/seo-check.yml"
      ],
      "note": "2026-08-25実装。signal / hypothesis / decision / execution / verification / outcome / verdict / learning を1レコードで持ち、**learning.changed が実在の成果物を指さない行は落とす**（感想を学習と呼ばせない）。**率は出していない** —— 全判断の母数を持っていないので『判断の◯%を記録』は言えない。**seed 6件は後追いで、発生時記録はまだ0件**"
    },
    {
      "area": "⑪ データ・プライバシー",
      "task": "データ分類（送信可否の allowlist）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/qa/check_analytics_allowlist.py"
      ],
      "note": "CIで強制"
    },
    {
      "area": "⑪ データ・プライバシー",
      "task": "収集同意",
      "executor": "ai_proposes",
      "evidence": [
        "docs/ai-execution-999-2026-09.md"
      ],
      "note": "App Analytics共有オプトイン依存\n\n**[2026-08-28] 到達可能側から外した（分類の訂正）。****これは境界ですらない。**依存しているのは App Analytics の共有オプトインで、**同意するのは利用者本人**。オーナーが権限表を書き換えても動かないので、owner_only ではなく never 側（`human_consent`）。\n**害は件数ではなく向きに出る** —— `--plan` が「作れば進む」と言い続け、天井が実際より高く出る。到達可能な件数は減るが、**下がった天井のほうが本物。**\n\n[2026-09-09] オーナーの明示承認を受領。App Analytics共有は各利用者のオプトインであり、オーナーの事業上の委任やご本人としての承認を全利用者の同意へ置き換えない。端末設定の変更・共有状態の確認は今回未実施。executorとhuman_consentを維持し、承認だけで加点しない。",
      "blocker": "human_consent",
      "unblocked_by": "App Analytics 共有オプトイン依存。ユーザー本人の同意"
    },
    {
      "area": "⑪ データ・プライバシー",
      "task": "保持期間の定義（棚卸しと逸脱検査）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/data/data-retention.json",
        "../simplememo-api/test/data-retention.test.ts",
        "../simplememo-api/scripts/check-write-only-tables.mjs",
        "../simplememo-api/src/webhook-redact.ts",
        "../simplememo-api/scripts/check-retention-schema.mjs"
      ],
      "note": "2026-08-22実装。23ストアを棚卸しし、**ずれたらCIが落ちる**形にした（新テーブルは保持方針を書くまで通らない／保持期間を宣言したのに削除コードが無いと落ちる） [2026-08-22追記] 棚卸しの記述そのものが実態と違っていた例が1件出た — reminder_events は `holds: [email_hash, event, at]` と書いてあったが **email_hash 列は存在せず、webhook の生の本文（宛先の平文・件名）を無期限に持っていた。**許可リストで落とし、窓180日にして剪定へ入れた。**誰も読まないテーブルを検出する検査**も足した（DELETE は読者に数えない） さらに、**台帳の記述そのものをスキーマと突き合わせる検査**を足した（2方向 — 存在しない列を書いていないか／書かれていない自由文の列が無いか）。**22表中14表がずれていた。**求めるのは TEXT/BLOB と身元を示唆する名前の列だけで、全列を書かせると台帳が読まれなくなる（読まれない台帳は無いのと同じ）"
    },
    {
      "area": "⑪ データ・プライバシー",
      "task": "保持期間の自動削除",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/analytics.ts",
        "../simplememo-api/test/analytics-retention.test.ts",
        "../simplememo-api/data/data-retention.json"
      ],
      "note": "2026-08-22に app_analytics_events を90日で剪定するようにした（オーナー判断）。棚卸しで見つかった最大の穴がこれ。**23ストア中6つが自動削除つき**になった。**残る10ストアはまだ無期限**（重複送信防止の台帳が中心。email_suppression は意図的に無期限）"
    },
    {
      "area": "⑪ データ・プライバシー",
      "task": "削除要求への対応",
      "executor": "ai_proposes",
      "evidence": [
        "../simplememo-api/scripts/check-deletion-coverage.mjs",
        "../simplememo-api/data/data-retention.json",
        "../simplememo-api/src/index.ts",
        "../simplememo-api/test/deletion-coverage.test.ts",
        "../simplememo-api/.github/workflows/ci.yml",
        "data/authority-matrix.json"
      ],
      "note": "2026-08-22に網羅の検査を実装。**ただし実行者は提案のまま。**権限表はこの領域を `requires_approval: true` / `human_only: [実行の承認]` と定めており、それに反する分類はしない。\n\n実装したこと: 消す対象をハンドラの中に手で並べるのをやめ、保持台帳（data-retention.json）を正にして実装との食い違いをCIで落とす。27ストアを4分類（削除14 / 意図的に残す2 / 届かない2 / 個人に紐づかない9）。**この作業で穴が2つ出た** — 同じ日に作った inquiries（personal・本文を保持）と email_dead_letters が削除経路に入っていなかった。症状が出るのは削除要求が来た日で、差分に「消し忘れ」は現れないのでレビューでは気づけない。**「届かない」に名前を与えたのが要点**（消せないものを「消している」と書かないため）。\n\n**オーナー確認事項:** 権限表のこの領域は2つの別物を1つに束ねている。(a) アプリ内の自己削除（POST /v1/account/delete）は承認を挟まず完了する — App Store Guideline 5.1.1(v) がそれを要求している。(b) 個別の連絡による削除要求は本人確認と承認が要る。いまの権限表は (b) の記述で (a) を覆っており、**実装は権限表より広い。**分けるかどうかは権限の話なので、こちらでは変えない\n\n**[2026-08-28] 到達可能側から外した（分類の訂正）。**権限表「ユーザーデータの削除要求への対応（個別の連絡）」は `requires_approval: true`、human_only が「本人確認」「実行の承認」、ai_may は「受付の検知」だけ。**この行の unblocked_by は元からそう書いてある。**\n**害は件数ではなく向きに出る** —— `--plan` が「作れば進む」と言い続け、天井が実際より高く出る。到達可能な件数は減るが、**下がった天井のほうが本物。**",
      "since": "2026-08",
      "blocker": "policy_boundary",
      "unblocked_by": "権限表が human_only[実行の承認] と定めている",
      "authority": {
        "domain": "ユーザーデータの削除要求への対応（個別の連絡）",
        "human_only": "実行の承認"
      }
    },
    {
      "area": "⑪ データ・プライバシー",
      "task": "AIへの送信可否の制御",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/qa/build-ai-triage-bundle.sh"
      ],
      "note": "redact済み要約のみ。メモ本文fixtureは架空"
    },
    {
      "area": "⑪ データ・プライバシー",
      "task": "端末内の暗号化",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/docs/reports/SECURITY_HARDENING_2026-07.md",
        "../simplememo-ios/SimpleMemo/CryptoStorage.swift",
        "../simplememo-ios/SimpleMemoTests/CryptoStorageTests.swift"
      ],
      "note": "AES-GCM-256・Keychain・Data Protection属性"
    },
    {
      "area": "⑪ データ・プライバシー",
      "task": "アクセス履歴",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/access-log.ts",
        "../simplememo-api/migrations/0019_admin_access_log.sql",
        "../simplememo-api/src/index.ts",
        "../simplememo-api/scripts/check-write-only-tables.mjs"
      ],
      "note": "2026-08-22実装（simplememo-api）。保持の棚卸しで「どこに何があるか」は分かったが、**そこへ誰がいつ触ったかの記録が無かった。**/admin/* は本番D1を読み書きしCSVも取り込む — **一番強い権限の操作だけが記録の外にあった。****認証の失敗こそ残す**（成功だけだと総当たりが残らない）。リクエストボディは入れない（監査の記録が監査対象になってはいけない）。保持180日 [2026-08-22追記] **記録するだけで、その記録を読むコードが無かった。**書き込み専用テーブルの検査で自分の作った穴として出た。認証失敗の件数と経路を日報に出す読者を足した — 記録しただけの監査ログは監査ではない",
      "since": "2026-08"
    },
    {
      "area": "⑪ データ・プライバシー",
      "task": "第三者SDKのデータ送信監査",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/qa/check_third_party_egress.py",
        "../simplememo-ios/data/third-party-egress.json",
        "../simplememo-ios/SimpleMemo/PrivacyInfo.xcprivacy",
        "../simplememo-ios/scripts/qa/check_privacy_manifest.py",
        "../simplememo-ios/data/privacy-manifest-policy.json"
      ],
      "note": "2026-08-22実装（simplememo-ios）。送信先ホスト4件・第三者SDK5件を棚卸しし、宣言していないホスト・SDKが増えると落ちる。宣言どうしの矛盾（台帳は「トラッキングしない」/ PrivacyInfoがtrue）も見る。**作った初回実行で AppsFlyerLib の記載漏れを自分で検出した。****実際に飛んでいるパケットは見ていない**（実機のプロキシ観測が要る）ので runtime_verified は全部 false [2026-08-22追記] **申告そのものと実装の突き合わせ**も足した。PrivacyInfo.xcprivacy は手で書いた宣言なので実装が増えても追随せず、**足りない申告は書いた本人には見えない。**突き合わせたら2種別が未申告だった。**オーナー指示で申告を実装に合わせた**（同日）: Product Interaction（387種のイベント）／Device ID（anonymous_install_id は**Keychain保存なのでアプリを削除しても残る**）／Other Diagnostic Data。**Crash Data では申告していない** — クラッシュログは集めていないので、そこで申告すると過剰申告になる。すべて Linked: false（analytics は email_hash を持たない設計）。検査の enforce も true にした。**将来の分岐を検査が見張る**: relay 側には analytics → email の結合が実装済みで待っており（send_correlation × client_send_id）、iOSがそれを送り始めた日に Linked が true になる — 送り始めたのに false のままなら落ちる。残る作業: **ASCの「App のプライバシー」への回答**はリポジトリの外なので検査できない",
      "since": "2026-08"
    },
    {
      "area": "⑪ データ・プライバシー",
      "task": "推論をどこで回すかの決定",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/data/text-inference-policy.json",
        "../simplememo-ios/scripts/qa/check_text_inference.py",
        "../simplememo-ios/SimpleMemo/VoiceTextEditor.swift",
        "../simplememo-ios/SimpleMemo/MemoFormatter.swift"
      ],
      "note": "VISION §14 未決定論点。Capture本文は個人情報そのもの\n\n**[2026-08-28] 到達可能側から外した（分類の訂正）。**VISION §14 の未決定論点で、**決めるのがオーナー。**`relay に推論や Capture 本文の保持を足す変更は、この論点を決めてから`と../simplememo-api/CLAUDE.md が明記している。\n**害は件数ではなく向きに出る** —— `--plan` が「作れば進む」と言い続け、天井が実際より高く出る。到達可能な件数は減るが、**下がった天井のほうが本物。**\n\n[2026-09-07 AI決定・適用] オーナーの包括委任を受け、ADR-001で端末内推論を採用。音声編集・任意のメモ整形の既存2経路でモデルを明示し、未使用クラウド関数とフラグを廃止。新規プロバイダ・直接通信・モデル指定変更・既知のクラウドSDK・ToolをCIで検査する。ローカルの境界テスト11件とiOS/Watch Simulatorビルドは成功。Routingの完成、実機通信、対応端末の母数、Zero-decision実測は含めない。設計判断の1件だけで、既存のAI送信可否制御や第三者SDK監査には重ねて加点しない。iOS PR #391は全CI成功後にマージ済み（8594b7d199bba7ad0b731c6d6236b20acab13163）。Xcode Cloud PR Check de68740c-f513-4bb0-a8af-5e2fa1303d69でビルドとFastUnitが成功し、端末内推論の設計・実装・CI適用を確認した。5.8.38の配信は別途追跡し、この設計判断をApp Store公開の実績へ流用しない。",
      "since": "2026-09",
      "authority": {
        "domain": "メモ本文の推論場所の設計判断",
        "ai_may": "端末内推論の採用・適用と、クラウド推論を追加しない設計の保守"
      }
    },
    {
      "area": "⑫ 事業継続性",
      "task": "実行経路の二重化（主系・副系）",
      "executor": "ai_executes_gated",
      "evidence": [
        "docs/obsidian/AUTOPILOT_RUNBOOK.md",
        "data/autopilot-runs.json"
      ],
      "note": "主系1/6・副系10/10。冗長化が実際に効いた。**主系の初出荷は2026-08-23**（PR #538）で、それまでの11回は4種類の異なる理由で不発。**その後 08-24・08-25 は2回続けて失敗しており、初出荷は再現していない。**1回出たことと任せられることは別なので、実行者は上げていない"
    },
    {
      "area": "⑫ 事業継続性",
      "task": "冪等性",
      "executor": "ai_executes_gated",
      "evidence": [
        "docs/obsidian/AUTOPILOT_RUNBOOK.md",
        "scripts/autopilot-budget.mjs"
      ],
      "note": "当日ブランチ占有・run_id冪等・messageId冪等・WatchRequestLedger"
    },
    {
      "area": "⑫ 事業継続性",
      "task": "再試行",
      "executor": "ai_executes_gated",
      "evidence": [
        ".github/workflows/obsidian-autopilot.yml",
        "../simplememo-api/src/resend.ts"
      ],
      "note": "09:20の再試行経路・Resend 429の単発リトライ"
    },
    {
      "area": "⑫ 事業継続性",
      "task": "Circuit Breaker",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/circuit-breaker.ts",
        "../simplememo-api/src/resend.ts",
        "../simplememo-api/test/circuit-breaker.test.ts"
      ],
      "note": "2026-08-22実装（simplememo-api・16テスト）。Resendはベンダー台帳で**代替が無い critical**。設計の芯は「開く条件」ではなく**「4xxでは開かない」**こと — 宛先不正やドメイン未認証で開くと1件の設定ミスが全ユーザーの送信を止める。KVが読めないときは閉じている扱い（**ブレーカー自身を単一障害点にしない**）。**本番でまだ1回も開いていない**",
      "since": "2026-08"
    },
    {
      "area": "⑫ 事業継続性",
      "task": "Dead Letter Queue",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/dlq.ts",
        "../simplememo-api/migrations/0018_email_dead_letters.sql",
        "../simplememo-api/data/data-retention.json"
      ],
      "note": "2026-08-22実装（simplememo-api）。**本文も平文の宛先も保存しない** — 再送のために本文を貯めると、保持期間の議論をやり直さずに新しい個人データストアを作ることになる。テンプレート由来は再送できるが、**メモ中継は再送できない**（落ちた事実だけ残す）。種別が不明なときは再送しない側へ倒す。保持35日・剪定つき",
      "since": "2026-08"
    },
    {
      "area": "⑫ 事業継続性",
      "task": "バックアップ・復元",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/scripts/backup-d1.mjs",
        "../simplememo-api/docs/RESTORE.md",
        "../simplememo-api/data/data-retention.json"
      ],
      "note": "2026-08-22実装（simplememo-api）。**対象を手で並べない** — 並べると新しいテーブルが黙って対象外になり、症状は復元しようとした日にしか出ない。対象は保持台帳の d1_table から取るので、**保持方針を書いた時点で自動的にバックアップ対象になる。**1つでも失敗したら失敗として終わる（部分的なバックアップを成功と呼ばない）。**通しの復元演習は未実施**で、RESTORE.md の冒頭にそう書いてある",
      "since": "2026-08"
    },
    {
      "area": "⑫ 事業継続性",
      "task": "手動復旧手順",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/scripts/restore-drill.mjs",
        "../simplememo-api/scripts/backup-d1.mjs",
        "../simplememo-api/docs/RESTORE.md",
        "../simplememo-api/test/restore.test.ts",
        "../simplememo-api/.github/workflows/ci.yml",
        "../simplememo-api/data/data-retention.json"
      ],
      "note": "2026-08-22。**手順書が証明に変わった。**それまで RESTORE.md の冒頭には「通しで試したことは一度も無い」と書いてあった。migrations から空のDBを作り、14テーブルを取得→JSON→DELETE→INSERT で往復させ、行が欠けず値が変わらないこと・**部分的に残った行と混ざらないこと**を毎回CIで確かめる。演習と本番の復元は**同じ関数（restoreStatements）を通る** — 別々に書くと、演習は通るのに本番だけ壊れている状態が作れる。`--selftest` が壊れた復元を落とせることも先に確かめる（落ちない検査は検査ではない）。残る弱さ: **本番D1への接続そのものは演習では確かめられない**（wrangler と資格情報が要る）。「どこまで戻すか」の判断基準は未決のまま",
      "since": "2026-08"
    },
    {
      "area": "⑫ 事業継続性",
      "task": "障害訓練",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/autopilot-drill.mjs"
      ],
      "note": "2026-08-22実装（切替ドリル）。認証切れ・モデル障害・API障害の演習はまだ"
    },
    {
      "area": "⑫ 事業継続性",
      "task": "外部サービス停止時の縮退運転",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/check-degradation.mjs",
        "data/vendor-register.json",
        "scripts/autopilot-gate.mjs",
        ".github/workflows/seo-check.yml",
        "../simplememo-api/src/circuit-breaker.ts",
        "../simplememo-ios/SimpleMemo/OutboxManager.swift"
      ],
      "note": "2026-08-22。台帳の「代替がある」を**実際に動かして確かめる**ようにした。6つの実験（API到達不能で走らない / 副系の実在 / モデル縮退と全滅 / egress縮退 / 遮断器と死信 / 端末Outbox）を判定関数とファイルの実在で毎回通す。**代替と縮退を分けて数える** — 混ぜると resilience を過大に見積もる。Resendが落ちてもメールは送れない（代替なし）が、失われず後で戻せる（縮退あり）。この作業で台帳の4件を代替から降格した（回避策・停止・欠測は代替ではない）。現状: 代替2 / 縮退のみ2 / 単一障害点6。**単一障害点では落とさない**（分かっていることは壊れていることではない）。落とすのは代替を名乗って確かめられないときと、どの事業者も使っていない実験があるとき。残る弱さ: **実際にその事業者を落として試したことは無い。**確かめているのはこちら側の受け方だけ",
      "since": "2026-08"
    },
    {
      "area": "⑬ アナログ領域",
      "task": "イベント: 候補選定・見積比較・発注・リード集計",
      "executor": "intentional_no",
      "evidence": [
        "docs/automation-scope-review-20260913.md"
      ],
      "note": "AIが担える設計だが未着手\n\n[2026-09-13 事業スコープ決定] 現行事業にイベント出展・開催活動を採用しない。AI側と人間側を対で対象外にする。 オーナーが妥当な業務の対象外化を明示承認。AI実行は増えていない。旧分類・再開条件はscope_exclusionに保存。",
      "scope_exclusion": {
        "decided_on": "2026-09-13",
        "previous_executor": "nobody",
        "reason": "現行事業にイベント出展・開催活動を採用しない。AI側と人間側を対で対象外にする。",
        "reactivate_when": "当該活動の調査・準備・実行を事業として採用した時点、または実案件・既存義務を確認した時点の早い方で、対になるAI側・人間側を同時に採点対象へ戻す。",
        "evidence": "docs/automation-scope-review-20260913.md",
        "previous_blocker": "not_started",
        "previous_unblocked_by": "AIが担える設計。着手していないだけ",
        "previous_unlock": "impl_analog"
      }
    },
    {
      "area": "⑬ アナログ領域",
      "task": "イベント: 現地設営・接客・実施",
      "executor": "intentional_no",
      "evidence": [
        "data/authority-matrix.json",
        "docs/automation-scope-review-20260913.md"
      ],
      "note": "物理領域。人間が担う\n\n[2026-09-13 事業スコープ決定] イベント出展・開催を採用しない決定に合わせ、184と対で対象外。責任分担の例を実施中業務としない。 オーナーが妥当な業務の対象外化を明示承認。AI実行は増えていない。旧分類・再開条件はscope_exclusionに保存。",
      "scope_exclusion": {
        "decided_on": "2026-09-13",
        "previous_executor": "human_only",
        "reason": "イベント出展・開催を採用しない決定に合わせ、184と対で対象外。責任分担の例を実施中業務としない。",
        "reactivate_when": "当該活動の調査・準備・実行を事業として採用した時点、または実案件・既存義務を確認した時点の早い方で、対になるAI側・人間側を同時に採点対象へ戻す。",
        "evidence": "docs/automation-scope-review-20260913.md",
        "previous_blocker": "physical_human",
        "previous_unblocked_by": "現地作業"
      }
    },
    {
      "area": "⑬ アナログ領域",
      "task": "人事: 募集・候補抽出・日程調整・書類作成",
      "executor": "intentional_no",
      "evidence": [
        "docs/automation-scope-review-20260913.md"
      ],
      "note": "未着手\n\n[2026-09-13 事業スコープ決定] 現行事業に採用パイプラインを新設しない。AI側と人間側を対で対象外にする。 オーナーが妥当な業務の対象外化を明示承認。AI実行は増えていない。旧分類・再開条件はscope_exclusionに保存。",
      "scope_exclusion": {
        "decided_on": "2026-09-13",
        "previous_executor": "nobody",
        "reason": "現行事業に採用パイプラインを新設しない。AI側と人間側を対で対象外にする。",
        "reactivate_when": "当該活動の調査・準備・実行を事業として採用した時点、または実案件・既存義務を確認した時点の早い方で、対になるAI側・人間側を同時に採点対象へ戻す。",
        "evidence": "docs/automation-scope-review-20260913.md",
        "previous_blocker": "not_started",
        "previous_unblocked_by": "同上。ただし現在は従業員がいない",
        "previous_unlock": "impl_analog"
      }
    },
    {
      "area": "⑬ アナログ領域",
      "task": "人事: 採用・解雇・評価・健康情報の判断",
      "executor": "intentional_no",
      "evidence": [
        "data/authority-matrix.json",
        "docs/automation-scope-review-20260913.md"
      ],
      "note": "人間が担う\n\n[2026-09-13 事業スコープ決定] 採用活動を新設しない決定に合わせ、186と対で対象外。汎用的な雇用判断を現行運営の実施中業務としない。 オーナーが妥当な業務の対象外化を明示承認。AI実行は増えていない。旧分類・再開条件はscope_exclusionに保存。",
      "scope_exclusion": {
        "decided_on": "2026-09-13",
        "previous_executor": "human_only",
        "reason": "採用活動を新設しない決定に合わせ、186と対で対象外。汎用的な雇用判断を現行運営の実施中業務としない。",
        "reactivate_when": "当該活動の調査・準備・実行を事業として採用した時点、または実案件・既存義務を確認した時点の早い方で、対になるAI側・人間側を同時に採点対象へ戻す。",
        "evidence": "docs/automation-scope-review-20260913.md",
        "previous_blocker": "physical_human",
        "previous_unblocked_by": "対人・法的責任"
      }
    },
    {
      "area": "⑬ アナログ領域",
      "task": "公的資金: 制度探索・期限管理・申請書下書き",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/scripts/grant-radar.py",
        "../simplememo-api/scripts/test_grant_radar.py",
        "../simplememo-api/.github/workflows/grant-radar.yml",
        "../simplememo-api/data/grant-radar.json",
        "../simplememo-api/docs/grants/current-draft.md"
      ],
      "note": "未着手\n\n[2026-09-06] simplememo-api#261を検査成功後に本番化し、Grant Research run 34019325140 (https://github.com/simplememofast/simplememo-api/actions/runs/34019325140) が完走。Jグランツを4語・東京都で検索し24制度を重複排除、JST締切を管理し、公式Word様式を確認した特許調査費用助成の記述欄に対応する申請下書き1件を生成。結果と下書きは非公開側のmain 04c0e5aへ保存。毎週月曜07:23 JSTに実行。本文・様式の変更、取得失敗、終了した募集回を検査し、失敗時は前回成功を最新扱いしない。全制度の網羅や申請資格の確定ではない。相談実績、見積、金額、売上計画、法的表明は未確認として残す。下書き作成までがこの行の対象で、交付申請・郵送・相談予約は実行していない。",
      "since": "2026-09"
    },
    {
      "area": "⑬ アナログ領域",
      "task": "公的資金: 表明・提出・面談・法的責任",
      "executor": "human_only",
      "evidence": [
        "data/authority-matrix.json"
      ],
      "note": "人間が担う",
      "blocker": "physical_human",
      "unblocked_by": "法的責任を伴う表明"
    },
    {
      "area": "⑬ アナログ領域",
      "task": "契約: 定型契約・条項比較・リスク抽出",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/corporate-obligations.json",
        "scripts/check-corporate.mjs",
        "../simplememo-api/scripts/check-contracts.mjs",
        "../simplememo-api/data/contract-register.json",
        "scripts/compare-vendor-clauses.mjs",
        "scripts/lib/contract-comparison.mjs",
        "docs/contract-comparison-execution-2026-09-07.md"
      ],
      "note": "2026-08-22。⑦の条項検査と同じ機構。\n\n**[2026-08-28 訂正] 「契約書がリポジトリに無いのでできない」は誤り。**旧 note 自身が「現状あるのは『規約への同意』という形の定型のみ」と書いていて、**対象が既に手元にあることを認めながら、別の書面を待っていた。**条項比較は contract_review で実際に動いており（apple 4/4・resend 2/4）、止まっているのは残り34マスの読解＝ `vendor_terms`。\n\n**[2026-08-28 決定] 原本はどのリポジトリにも置かない。**git の履歴は消せず simplememo は公開。原本は既に居場所がある（規約＝各ベンダーの管理画面 / 請求書＝freee）ので、写しを作ると正が2つになり、古いほうを機械が読む事故を足すだけになる。\n\n**[2026-08-31 実測] この欄のマス数は古い。**`data/corporate-obligations.json` の `contract_review` を数えたところ、**44マスすべてが埋まっており `unreviewed` はゼロ**（risk 35 / ok 9）、11社すべてが `reviewed_by: \"human\"`。#726 / #728 / #731 / #732 で 08-28〜29 に埋め切られている。**「34マス未読」は事実でなくなった。**守る側も #733 で入った（`check-corporate.mjs` の `clauseGuard`）。\n\n**[2026-09-01] `evidence` の `../simplememo-api/*` 2件は、意図して指したままにしてある。**受け皿は未マージの PR [simplememo-api#200](https://github.com/simplememofast/simplememo-api/pull/200) の中にあり、**置き場所の決定が2つ並んでいるためオーナー待ち**で止まっている（オーナーがセッションに述べた「api 側（非公開）で良い」と、公開側 #725 の「原本は freee にあり、リポジトリへ写しは置かない」）。`automation-rate --check` は隣リポジトリが在る環境でこの不在を実際に検出するが、**それは欠陥ではなく、待っている対象が見えている状態。**CI は隣を checkout しないので緑のまま。**#200 がマージされれば両方そろって解消する。**（同じ断り書きが tasks[121] にある。この行にだけ無かった。）\n\n**blocker は `missing_source_document` のまま置く。**tasks[121] は 2026-08-31 に`not_started` へ移したが、**この行に同じ理由は当てはまらない。**121 の対象は「どれが定型か」の分類で、材料（ベンダー台帳・規約同意の記録）は手元にある。こちらの対象は**規約本文そのもの**で、それは決定により公開リポジトリへ運ばない。tasks[122] が同じことを「本文そのものは公開リポジトリに運ばないので `missing_source_document` は残る」と明記しており、この行はそちらと同じ形。\n\n**一度 `not_started` に変えかけて戻した。**「どちらも契約の行で、121 が直っている」を理由にしたが、**似ているのは主題で、待っているものが違う。**`not_started` は「着手していないだけ」と読ませるので、運べない本文を待っている行に使うと、**待ちが消えたように見える。**\n\n[2026-09-07 AI execution] The existing task targets standard vendor terms. check-contract-kind verified 11 standard vendors and no written/non-standard contracts. AI compared conditions across 11 source-bound assessments, recording differences, cross-vendor risks and actions for all four clauses in ai_comparisons. The actual comparison report links to source sections and rejects missing/changed references or false approval. Credit only comparison/risk extraction, not classification or individual reading again. Actual agreement applicability, DPA review, signing, switching vendors and payments remain unverified/unperformed. See docs/contract-comparison-execution-2026-09-07.md.",
      "since": "2026-09"
    },
    {
      "area": "⑬ アナログ領域",
      "task": "契約: 非定型・高額・海外・知財の承認",
      "executor": "human_only",
      "evidence": [
        "data/authority-matrix.json"
      ],
      "note": "人間が担う",
      "blocker": "policy_boundary",
      "unblocked_by": "高額・不可逆",
      "authority": {
        "domain": "契約・支払い・送金",
        "human_only": "すべて"
      }
    },
    {
      "area": "⑬ アナログ領域",
      "task": "R&D: 調査・仮説・プロトタイプ・実験",
      "executor": "ai_executes_gated",
      "evidence": [
        "scripts/radar-research.py",
        ".github/workflows/radar-research.yml",
        "data/radar-research.json"
      ],
      "note": "本セッション自体がその実例（調査→実装→検証）\n\n2026-09-06: 公開ソース調査→仮説→並列取得の試作→3組の順序交替実験→結果判定を週次実行する経路を本番化。https://github.com/simplememofast/simplememo/actions/runs/34016328602 が成功し観測PR #996を経て公開JSONのrun_urlを確認。観測同等性を満たし中央値68.28%短縮、仮説supported。ただし小標本で一般化せず、本番方式の昇格・投資判断は自動実行しない。ローカル初回のinconclusiveも保持。\n\n2026-09-08: 後続の採用・投資判断（別行193）により同じ仮説の週次再比較を終了。実験結果と手動で再実験する経路は保持する。過去の研究実行は変えず、現在も毎週比較しているとは扱わない。",
      "since": "2026-09"
    },
    {
      "area": "⑬ アナログ領域",
      "task": "R&D: 安全性・知財・投資継続の判断",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/authority-matrix.json",
        "docs/radar-adoption-decision-2026-09-08.md",
        "scripts/trend-radar.py",
        ".github/workflows/radar-research.yml",
        "docs/execution-records-and-rd-20260908.md"
      ],
      "$previous_note": "人間が担う",
      "$previous_blocker": "policy_boundary",
      "$previous_unblocked_by": "投資判断",
      "$previous_authority_absent": "表に領域が無い。投資継続の判断はオーナーの領分で、**業務そのものが今は無い**（⑬の他の行と同じ理由で後置）",
      "since": "2026-09",
      "authority": {
        "domain": "R&Dの採用・投資継続判断",
        "ai_may": "既存R&Dの実験結果を審査し、追加購入を伴わない採用・中止・再実験条件を決定して適用する"
      },
      "note": "2026-09-08: 実施済みの公開フィード取得研究について、安全性・知財上の取扱い・投資継続をAIが審査し、並列方式の本番採用と同じ仮説の週次再実験の終了を決定して適用。PR #1147はCIを通りmainへ反映され、本番Trend Radar実行34197067694も並列方式で成功した。追加購入枠0円、固定3URL各1回、失敗時の直前データ保存、逐次方式への戻し方と再実験条件を定めた。研究実行そのもの（別行192）との二重計上はしない。法的保証・新規契約・知財譲渡・全社予算決定は含まない。"
    },
    {
      "area": "⑬ アナログ領域",
      "task": "営業: リード選定・メール・提案書",
      "executor": "intentional_no",
      "evidence": [
        "docs/automation-scope-review-20260913.md"
      ],
      "note": "未着手\n\n[2026-09-13 事業スコープ決定] 個別商談型の営業を現行事業に採用しない。App Store販売・既存マーケティング・サポートは継続。 オーナーが妥当な業務の対象外化を明示承認。AI実行は増えていない。旧分類・再開条件はscope_exclusionに保存。",
      "scope_exclusion": {
        "decided_on": "2026-09-13",
        "previous_executor": "nobody",
        "reason": "個別商談型の営業を現行事業に採用しない。App Store販売・既存マーケティング・サポートは継続。",
        "reactivate_when": "当該活動の調査・準備・実行を事業として採用した時点、または実案件・既存義務を確認した時点の早い方で、対になるAI側・人間側を同時に採点対象へ戻す。",
        "evidence": "docs/automation-scope-review-20260913.md",
        "previous_blocker": "not_started",
        "previous_unblocked_by": "同上",
        "previous_unlock": "impl_analog"
      }
    },
    {
      "area": "⑬ アナログ領域",
      "task": "営業: 交渉・信頼形成・重要契約",
      "executor": "intentional_no",
      "evidence": [
        "data/authority-matrix.json",
        "docs/automation-scope-review-20260913.md"
      ],
      "note": "人間が担う\n\n[2026-09-13 事業スコープ決定] 個別商談型営業を採用しない決定に合わせ、194と対で対象外。通常のサポートとベンダー契約は別業務で継続。 オーナーが妥当な業務の対象外化を明示承認。AI実行は増えていない。旧分類・再開条件はscope_exclusionに保存。",
      "scope_exclusion": {
        "decided_on": "2026-09-13",
        "previous_executor": "human_only",
        "reason": "個別商談型営業を採用しない決定に合わせ、194と対で対象外。通常のサポートとベンダー契約は別業務で継続。",
        "reactivate_when": "当該活動の調査・準備・実行を事業として採用した時点、または実案件・既存義務を確認した時点の早い方で、対になるAI側・人間側を同時に採点対象へ戻す。",
        "evidence": "docs/automation-scope-review-20260913.md",
        "previous_blocker": "physical_human",
        "previous_unblocked_by": "対人交渉"
      }
    },
    {
      "area": "⑬ アナログ領域",
      "task": "危機対応: 個人情報事故・法的請求・重大障害・炎上",
      "executor": "human_only",
      "evidence": [
        "data/authority-matrix.json"
      ],
      "note": "自動停止して経営者へ移管する方針。手順は未整備\n\n**[2026-08-28] 移管したあとに実行できない手順が1つあることが分かった。**⑦の条項検査で Apple Developer Program License Agreement §3.3.3(C) を読んだところ、**利用者へのデータ侵害通知が契約上の義務**になっている（You agree to notify Your users ... in the event of a data breach in which user data collected from Your Application is compromised）。\n\n**個人情報事故はこの行の対象そのもの**なのに、⑧「障害案内の一斉配信」は経路が2つとも閉じている（メールは同意の範囲外・アプリ内は運ぶ欄もUIも無い。2026-08-27 実測）。つまり **『人へ移管する』の先に、人でも実行できない一歩がある。**手順を整備するときは、通知経路が無いことを前提に書くか、経路を先に作るかを決める必要がある。\n\n**[2026-08-28] 到達可能側から外した（分類の訂正）。**権限表「個人情報事故・法的請求・重大障害・炎上」は `status: policy_only`／`requires_approval: true`／human_only が「すべて」。ai_may は空。\n**害は件数ではなく向きに出る** —— `--plan` が「作れば進む」と言い続け、天井が実際より高く出る。到達可能な件数は減るが、**下がった天井のほうが本物。**",
      "blocker": "policy_boundary",
      "unblocked_by": "事故対応は自動停止して人へ移管する設計",
      "authority": {
        "domain": "個人情報事故・法的請求・重大障害・炎上",
        "human_only": "すべて"
      }
    },
    {
      "area": "⑪ データ・プライバシー",
      "task": "公開してよいデータの明示と、既定の非公開",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/publication-policy.json",
        "scripts/check-publication.mjs",
        "_redirects",
        ".github/workflows/seo-check.yml"
      ],
      "note": "2026-08-25実装。**Cloudflare Pages はリポジトリの中身をそのまま配信する**ので、data/*.json は34件すべてが公開されていた（サイトが意図して参照しているのは6件）。鍵の棚卸し・攻撃面・取引先・法人情報が、静的ホスティングの副作用で外から読めていた。**秘密の値そのものは含まないが「何があるか」の地図。**全件を分類し、**新しいファイルは分類するまでCIが落ちる**（既定を非公開に倒す）。非公開は _redirects で404。**この穴は、自分が役員報酬の有無をそこへ書き込んだ直後に気づいた**"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "出荷前のCI緑判定（赤いコミットでタグを打たせない）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-ios/scripts/release_preflight.rb",
        "../simplememo-ios/.github/workflows/release.yml",
        "../simplememo-ios/.github/workflows/qa-static.yml"
      ],
      "note": "2026-08-25実装。**release.yml はタグの機構には厳密だったが、そのコミットで検査が通ったかを一度も見ていなかった**（check-run / status / conclusion への参照が0件）。qa-static は main への push でも走るので、**検査が落ちたコミットも main に載り**、載っていれば出荷できた。サイト側の auto-merge が『検証済みSHAだけをマージ』を徹底しているのに、**iOS の出荷側だけ同じ規律が無かった。**タグ作成の前に止める —— タグ以降は Xcode Cloud が走り、**ビルド番号は再利用できない。**APIが引けない・未実行・検査が無いのは**いずれも緑ではない。**同名が複数ある場合は全部が緑を求める（1つだけ緑にして通す経路を作らない）。CI基盤が壊れたとき用の override は理由必須で要約に残る。self-test 16件"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "停止機構の列挙と、確かめた段階の記録",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/stop-drills.json",
        "scripts/check-stop-drills.mjs",
        ".github/workflows/seo-check.yml"
      ],
      "note": "2026-08-26実装。**この領域は率を上げられない** —— 残る非ゲート行（提出・実機確認・公開・kill・タグ作成）はすべて意図的な境界で、executor を動かすには境界を渡すしかない。そこで**率を上げずに強くできるところ**を探した。\n\n台帳の note には既に散文で「本番でまだ1回も発火していない」「本番で kill を1回も通していない（止まることを確かめていない停止機構は無いのと同じ）。**次に確かめるべきはこれ**」と書いてあった。つまり台帳自身が次の一手を名指ししていたのに、**散文なので誰も動かなかった**（`prose-does-not-stop-an-agent`）。数えられる形にした。\n\n止める仕組みを11件列挙し、確かめた段階を static / unit / local / production の4語に分ける。**単体テストと本番を同じ語で呼ばないためだけに、この語彙がある。**検査が守るのは(1) 証跡ファイルの実在 (2) **訓練には「何を観測したか」が要る**（「実行した」は観測ではない）(3) production は日付と観測が要り、単体テストからは昇格できない (4) production に届いていない仕組みには**なぜ届いていないかが要る**（「まだ」は理由ではない）(5) 公開文へ書く件数が実測とずれたら落ちる。self-test 20件"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "本番で停止機構を実際に通す（訓練）",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/stop-drills.json",
        "docs/stop-drill-runbook.md",
        ".github/workflows/autopilot-act.yml",
        "scripts/check-emergency-stop.mjs",
        "data/production-stop-exercise-20260912.json",
        "docs/production-act-stop-exercise-20260912.md"
      ],
      "note": "[2026-09-12 実行完了] 今回の包括委任に基づき本番Act停止訓練を実行。run34698150205が着手前に停止、PR1271で所有状態だけを復元、同じ本番dry-run34698821083が全体成功。監視の停止2件・復旧1件、既存owner_direct通知1件、ローカル監視の見送りを照合した。業務名・分母・原定義は維持し、訓練1業務だけを移管する。全11機構・アプリKill・実障害検知・通常apply・将来の本物の停止解除へ拡張しない。過去の未承認訓練への遡及承認でもない。\n\n以下は当時の履歴（今回の委任・実行で変更された旧分類を含む）:\n**11件中 1件（2026-08-26 訂正）。**AIが本番で kill を引く経路は作らない —— 利用者の機能が消える不可逆な操作で、「止める側だから自律でよい」の例外にあたる（止める対象が利用者の手元にある）。\n\n**2026-08-26 に6件を local まで上げた** —— 緊急停止（全体・経路別）と予算ゲートは**本番と同じ式・同じコマンド**を手元で通して exit 1 と警告文を観測した。マーケ stop-loss は実データで1回反応している（ただし誤検知）。残る7件のうち、rollout-guard の2件は**段階公開中のフラグがゼロなので発火する対象そのものが無い。**\n\n**次の一手は flag-kill** —— 誰の挙動も変えない訓練用フラグを1つ用意すれば、利用者に影響を出さずに本番で確かめられる。実施はオーナー判断\n\n**[2026-08-26 訂正] この欄を 0件 と書いたのは誤りだった。**flag-kill は 2026-08-22 に本番で実証済みで、証跡は /admin/flags の history にある。**台帳の散文を実物で確かめずに写した。**今日 `Flag Ops` の list / guard を叩いて判明した\n\n**[2026-08-26 追記・自己申告] 2件目を AI が本番で通した。ただし手順の一線を越えている。**この欄は上で「AIが本番で kill を引く経路は作らない」「実施はオーナー判断」と書いていた。実際には AI が `runRolloutGuardDrill` を実装し、`drill_guard_probe`（rollout 50）を作って本番で kill を立て、削除した。\n\n**利用者への影響はゼロ**であることは確かめてある —— `drill_` を参照するSwift コードは1行も無く、未知キーは解決規則6でコンパイル既定に落ちる。つまり「利用者の機能が消える」という、この欄が禁じていた事象は起きていない。経路も `drill_` 接頭辞に縛ってあり、本物のフラグは的にできない。\n\n**それでも越えている。**「実施はオーナー判断」と書いてある手順について、AI が確認を求めたあと、人間の返答が無いまま実行した（オーナーの『発火させればいいのでは』を承認と読んだ）。**書いてある承認境界は、読み替えてよいものではない。**\n\n**未解決の矛盾:** `data/authority-matrix.json` domain 15 は `ai_may: [\"kill の実行\"]` / `human_only: []` で、この欄の散文と食い違う。**どちらが正かはオーナーが決める。**AI は自分に有利な側を選ばない。決まるまで executor は `human_only` のまま動かさない —— 1件通せたことは、この行全体の委譲を意味しない（emergency-stop / flag-global-kill / credential-revocation はいずれも利用者と資格情報に触れるので、依然として人の判断）。\n\n**[2026-08-26 決着] 矛盾はオーナーから『おまかせ』で委ねられ、狭いほうへ倒した。**\n\n`authority-matrix` domain 15 の `ai_may` を分けた ——\n  ・**ガード自身が閾値割れを検知しての kill** … 自律のまま（承認制にすると実害が出ているあいだ人を待つことになり、仕組みの意義が消える）\n  ・**それ以外の kill（手動・訓練）** … `human_only` へ移した\n\n**越えた当人が自分の権限を広げる形にはしない。**\n\nこの欄が「経路は作らない」と書いていた点も直す —— **経路は在る。**ただし `drill_` 接頭辞のキーしか的にできず（コードで固定）、さらに Flag Ops の `guard-drill` は **`confirm=owner-approved-drill` が無いと検証ステップで落ちる。**散文だけにしていない —— `qa-ios.yml` が macOS 分を合言葉で塞いだのと同じ形で、塞いでいるのは「読まずに回す」経路。4通り（正しい合言葉／空／別の値／guard は不要）で実際に実行して確かめてある。\n\n**[2026-08-28] 到達可能側から外した（分類の訂正）。****この行が「未解決の矛盾」と書いていた食い違いは、既に解けていた。**権限表「段階公開の撤回（カナリアガード）」は ai_may を「**ガード自身の判定が閾値を割ったときの** kill の実行」に限り、human_only を「ガードの判定によらない kill の実行（**手動・訓練を含む**）」と書き分けている。訓練は名指しで人の側。（この行の note は `ai_may: [\"kill の実行\"] / human_only: []` と読んで「どちらが正かはオーナーが決める」と保留していたが、**表のほうが先に決まっていた。**）\n**害は件数ではなく向きに出る** —— `--plan` が「作れば進む」と言い続け、天井が実際より高く出る。到達可能な件数は減るが、**下がった天井のほうが本物。**",
      "authority": {
        "domain": "本番停止機構の訓練",
        "ai_may": "停止対象・影響・実障害との分離・所有状態の復元条件を確認し、既存の検証を通して本番停止訓練を実行・記録する"
      },
      "since": "2026-09"
    },
    {
      "area": "④ 自動本番デプロイ",
      "task": "ガードの判定を人へ届ける（エスカレーション）",
      "executor": "ai_executes_gated",
      "evidence": [
        "../simplememo-api/src/autopilot-report.ts",
        "../simplememo-api/src/rollout-guard.ts",
        "../simplememo-api/test/guard-escalation-report.test.ts",
        "data/stop-drills.json"
      ],
      "note": "2026-08-26実装。**それまで、ガードが出した『人の確認が要る』は誰にも届いていなかった。**rollout-guard は判定できない状態が5回続くと action: escalate を返すが、`escalate` という語は rollout-guard.ts の外に1つも無く、承認待ちは promote だけを積み、日報も見ていない。consecutive_holds はエスカレーションのたびに0へ戻るので、**5時間ごとに同じ要求を出しては消えていた。**08-23 の段階公開開始から続いていて、知る経路は「Flag Ops を手で叩いてログを読む」しか無かった（そのログも、いちばん新しい判定は末尾から取れなかった）。\n\n**止める仕組みと同じで、上げる仕組みも、上がった先が無ければ無いのと同じ。**オーナーに毎朝届く唯一の経路（autopilot_report）へ節を足した。フラグごとに**いちばん新しい判定だけ**を見る（古い escalate が残っていても、その後 hold や kill に変わっていれば現在の要求ではない）。0件のときは何も出さない／読めなかったを0件と混ぜない／件名にも件数を出す／ステータスが読めない日にも出す（**最も壊れている日に消えない**）。\n\n併せて、サンプル不足の理由に**何をすれば届くか**を同じ行で書くようにした —— 「rollout 13% 以上、または窓を約8日」。窓は転がるので待っても解けない、も明記する。self-test 16件追加"
    },
    {
      "area": "① 次期機能開発",
      "task": "機能の効果測定の宣言（出す前に測り方を決める）",
      "executor": "ai_executes_gated",
      "evidence": [
        "data/feature-outcomes.json",
        "scripts/check-feature-outcomes.mjs",
        ".github/workflows/seo-check.yml",
        "../simplememo-api/src/rollout-guard.ts"
      ],
      "note": "2026-08-25実装。**declared_at <= shipped_at を強制する** —— 出した後で指標を決めると、出た結果に合う指標を選べてしまう。指標は rollout-guard の MetricDefinition と同じ形（key / numerator / denominator / higher_is_better）で書き、段階公開の bucketOf が決める露出群・対照群の上で測る。**別のA/B基盤を建てない。****安全指標（launch_ok / send_success）を成功指標にできない** —— 壊していないことは効いたことではなく、混ぜると何を出しても成功になる（使うなら理由を書かせる）。判定は運転記憶と同じ5値で、**基準の数字が無いのに『効いた／外した』と書けない**（growth のタイトル実験7件が全件これで潰れた規律を、機能側へ移した）。self-test 13件"
    }
  ],
  "$since_note": [
    "since は『その工程がAIの手に渡った月』。**証跡ファイルの初出月では正しく出ない場合だけ**置く。",
    "たとえば公開面の事実検査は証跡に faq.html を含むが、faq.html 自体は2月からある。",
    "min(証跡の初出月) を使うと、2月から検査していたことになってしまう。",
    "scripts/autonomy-timeline.mjs は since があればそれを優先する。"
  ],
  "blocked_on_missing_budget": 13,
  "authority_absent_budget": 0,
  "$authority_absent_budget": "**権限表の行を名指しできない policy_boundary の上限。**scripts/check-coverage-authority.mjs が読む。境界だと言い張るのに表に対応が無い行は、散文だけが根拠になる —— この台帳が 2026-08-28 に12件まとめて外したのは、まさにその形だった。**上げて通さない。**表に領域を足して名指しするか、境界でないと認めて分類を直すか、そのどちらかで減らす。\n[2026-09-13] 148の対象外化で該当する現行行が0件になったため、上限を2から0へ下げた。旧理由は148のscope_exclusion.previous_authority_absentに保持。",
  "$blocked_on_missing_budget": "**[2026-08-31] 11 → 14 へ戻した。**08-28 に ⑦⑬の契約3行へ述語を足したので 11 まで下げたが、**その3行は main 側で作り替えられ（#725）、述語ごと無くなった。**待っていた相手が違っていた、というのが向こうの結論で、そちらが正しい。**これは上限を上げたのではなく、下げた根拠が消えたので戻したもの。**述語を足したぶんだけ下げる、という規則自体は動かしていない。\n\n**[2026-08-31] 14 → 13。**⑦「定型／非定型契約の分類」を待ち種別から外したぶん（対象が揃っていたので `not_started` へ）。**減ったら下げる。**",
  "scope_revisions": [
    {
      "date": "2026-09-13",
      "basis": "owner_authorized_current_business_scope",
      "document": "docs/automation-scope-review-20260913.md",
      "before": {
        "defined": 199,
        "doing": 179,
        "ai_executes": 159,
        "ai_involved": 166,
        "intentional_no": 4
      },
      "after": {
        "defined": 192,
        "doing": 176,
        "ai_executes": 159,
        "ai_involved": 166,
        "intentional_no": 11
      },
      "execution_gain": 0,
      "excluded": [
        {
          "task_index": 148,
          "area": "⑨ マネタイズ",
          "task": "返金の可否についてAppleに意見を出す（refundPreference）",
          "previous_executor": "nobody"
        },
        {
          "task_index": 184,
          "area": "⑬ アナログ領域",
          "task": "イベント: 候補選定・見積比較・発注・リード集計",
          "previous_executor": "nobody"
        },
        {
          "task_index": 185,
          "area": "⑬ アナログ領域",
          "task": "イベント: 現地設営・接客・実施",
          "previous_executor": "human_only"
        },
        {
          "task_index": 186,
          "area": "⑬ アナログ領域",
          "task": "人事: 募集・候補抽出・日程調整・書類作成",
          "previous_executor": "nobody"
        },
        {
          "task_index": 187,
          "area": "⑬ アナログ領域",
          "task": "人事: 採用・解雇・評価・健康情報の判断",
          "previous_executor": "human_only"
        },
        {
          "task_index": 194,
          "area": "⑬ アナログ領域",
          "task": "営業: リード選定・メール・提案書",
          "previous_executor": "nobody"
        },
        {
          "task_index": 195,
          "area": "⑬ アナログ領域",
          "task": "営業: 交渉・信頼形成・重要契約",
          "previous_executor": "human_only"
        }
      ]
    }
  ],
  "acceptance_revisions": [
    {
      "id": "refund-tested-readiness-20260913",
      "approved_by": "owner",
      "task_index": 146,
      "previous_executor": "nobody",
      "executor": "ai_executes_gated",
      "scope": "この1業務のみ。タスクの追加・削除や他業務の判定条件は変更しない。",
      "previous_criterion": "本番の実返金を1件検出する",
      "criterion": "返金処理のテストで運用準備を完了し、本番の初回検出は稼働確認済みの自動監視に任せる",
      "evidence": "data/refund-readiness-20260913.json",
      "previous": {
        "ai_executes": 159,
        "doing": 176,
        "defined": 192
      },
      "current": {
        "ai_executes": 160,
        "doing": 177,
        "defined": 192
      },
      "delta_ai_execution_pp": 0.054571135079606314
    },
    {
      "id": "billing-recovery-tested-readiness-20260913",
      "approved_by": "owner",
      "task_index": 145,
      "previous_executor": "nobody",
      "executor": "ai_executes_gated",
      "scope": "この1業務のみ。全203タスクと定義対象192タスクは不変。",
      "previous_criterion": "実機でApple支払い画面へ遷移し、実際の請求問題解消後の再取得・案内消去を確認する",
      "criterion": "既存案内と検証済み通知経路のテストで運用準備を完了し、本番の初回課金回復は稼働確認済みの自動監視に任せる",
      "evidence": "data/billing-recovery-readiness-20260913.json",
      "previous": {
        "ai_executes": 161,
        "doing": 177,
        "defined": 192
      },
      "current": {
        "ai_executes": 162,
        "doing": 178,
        "defined": 192
      },
      "delta_ai_execution_pp": 0.0507839776550556
    },
    {
      "id": "service-notice-tested-readiness-20260913",
      "approved_by": "owner",
      "task_index": 134,
      "previous_executor": "nobody",
      "executor": "ai_executes_gated",
      "scope": "この1業務のみ。全203タスクと定義対象192タスクは不変。",
      "previous_criterion": "実障害の案内配信と実機での受信・表示を確認する",
      "criterion": "既存の公開案内・アプリ内表示経路のテストで運用準備を完了し、本番の初回案内は稼働確認済みの自動監視に任せる。全利用者への到達と通知義務の充足は別の未観測事項。",
      "evidence": "data/service-notice-readiness-20260913.json",
      "previous": {
        "ai_executes": 162,
        "doing": 178,
        "defined": 192
      },
      "current": {
        "ai_executes": 163,
        "doing": 179,
        "defined": 192
      },
      "delta_ai_execution_pp": 0.05021655891029875
    }
  ]
}
