🔁 Ritual Mechanism Doctrine
月次・四半期にしか発火しないが、放置すると確実に痛む — そんなタスクを「視界から消えると死ぬ」前に救う、再現可能な 5 モジュール architecture。
📌 解こうとしている問題
個人の生産システムにも、組織のオペレーションにも、繰り返し現れる致命的なパターンがある:
頻度が低い(月次・四半期)。
スキップすると後で必ず痛い(コンプラ・金銭・整合性)。
本人は意識的に避けるか先送りする。
forcing function なしには、確実に死ぬ。
このタイプのタスクは、視界から消えた瞬間に蓄積を始め、何ヶ月か後に大手術として返ってくる。日次の triage では捕まらず、四半期の振り返りでは手遅れ。
本 doctrine は、この「ritual class」のタスクを、**人間の意志に依存しない仕組み**に落とすための標準 architecture を定義する。
🎯 適用シグナル(本 doctrine を使うべき task の特徴)
| 軸 | 判定 |
|---|---|
| 頻度 | 月次以下(週次なら daily 系で十分) |
| 必須度 | スキップすると後で必ず痛い |
| 苦手度 | 本人が意識的に避ける / 先送りしがち |
| 抽出可能性 | 何らかの state(file system / API / mail)から自動 scan 可能 |
合致しない例: 高頻度の日次 triage、個別判断が中心で bulk 化できないタスク。
🧩 5 モジュール architecture
| M# | 役割 | 典型成果物 |
|---|---|---|
| M1 Generator | 候補抽出 / template 生成。State を scan して「やるべき候補」を構造化出力。 | YAML manifest + Markdown summary |
| M2 Engine | 実行 / 突合。承認された候補を applied state にする。 | 突合 JSON / bulk apply script(dry-run gate 必須) |
| M3 Integration | Manager による物理 verify + end-to-end smoke。Worker 出力は untrusted 前提で independent 確認。 | 統合報告書 |
| M4 Platform 連携 | 判断キュー(decision-first card)を常設し、aging 検知時に上位入口へ自動浮上。 | Reference card + aging-injection proposal |
| M5 Skill packaging | エントリポイント skill 化。トリガーフレーズ 1 つで全 phase が連鎖。 | SKILL.md + phases/ + docs/ |
🛠️ Build pattern — W1 → W2 → W3
W1: Contracts(Manager 単独・1 turn)
インターフェース(schema / 禁則 / I/O 仕様)を確定。全 worker の共通基盤になる。飛ばすと W2 成果物がバラバラになり、W3 で全部やり直す。
W2: Parallel workers(~5 分 wall clock)
4 worker を disjoint path に dispatch。Sonnet 級の executor agent で十分。並列はトークン予算がある時のみ(リミット間際は封印)。
W3: Manager integration + smoke gate
Worker 出力は untrusted 前提で物理 verify(Glob/Read で実在確認)→ end-to-end smoke → 統合報告書 → 残課題明示。9 割完成で止め、最後の 1 割(実地検証・承認 gate)は人に渡す。
🛡️ Safety doctrine(操作種別で変動)
| 操作種別 | Safety layer |
|---|---|
| Read-only Local 生成のみ | 最終外部実行(submit / send)は人 |
| Destructive Frontmatter 更新 / 物理 move 含む | + dry-run default + --apply --confirm <key> 二段 gate + idempotent + audit log append-only + 完全削除絶対禁止 |
| External API 外部呼出を含む(将来) | + per-call user 承認 + 監査記録 + ロールバック手順明示 |
📦 Skill packaging 規律
- SKILL.md はエントリポイントのみ(80-100 行)、詳細は
phases/+docs/に分離 - 冒頭に禁則を明示(操作種別に応じた数 — read-only なら 5 項目 / destructive なら 8 項目)
- phases:
generate/[review]/applyorreconcile/integrate - docs:
contracts.md(schema)+gotchas.md(番号体系)+[safety.md](destructive 時のみ) - 既存 skill との棲み分けを明記(daily / weekly / monthly retrospective との関係)
⚠️ Anti-pattern(やってはいけない)
- 1 instance で doctrine 抽象化 — 本 doctrine も 2 instance 完成を待った
- Destructive ops を skill 内で auto-apply(必ず二段 gate)
- Canonical(daily 系)skill を ritual mechanism worker が直接 mutate(提案ファイル経由必須)
- Worker 出力を verify せず信頼(Manager で物理 verify が原則)
- W1 (contracts) を飛ばして W2 dispatch(成果物がバラバラに)
- Ritual を「読み物」にする(decision-first 違反、判断キュー形式必須)
🌱 次の適用候補(本 doctrine を再利用)
| 候補 | 頻度 | 抽出可能性 |
|---|---|---|
| 四半期 retrospective | 四半期 | 高(週次出力を集約) |
| 年次 archive | 年 | 高(folder mtime + index) |
| 定期 progress audit | 月 | 中(契約管理 sheet 等) |
| sync 検証 | 週-月 | 高(diff 検出) |
🧠 設計哲学 — なぜこの形なのか
「視界から消えると死ぬ」タスクを救うのは、本人の意志でも、daily の triage でもなく、aging 検知 → 上位入口への自動浮上 → 二段 gate での慎重実行という構造そのもの。
仕組みは、人間の規律の代替ではない。規律が必要な瞬間を減らすためのもの。