| name | weekly-gate |
| description | 土曜の単一承認セッション（ADR-0085）。無人 weekly チェーンが生成した承認パケット（weekly-{end-date}-packet.md）を読み、code patch の apply → Verify → 単一 commit、prompt diff の本文承認、insight staging の adopt-staged、gate メトリクスの記録までを 1 セッションで行う。Use when the user says 「週次の承認をする」「packet をレビューする」/weekly-gate, or on Saturday after the unattended chain has produced a decision packet. |
| origin | shimo4228 |
| user-invocable | true |
Weekly Gate — 土曜の単一承認セッション
無人チェーン（scripts/weekly-pipeline.sh、ADR-0085）は commit も adopt もしない。
このセッションが週 1 回の人間ゲートであり、CYCLES.md の昇格エッジ #5（findings →
code/ADR/task）と #6（実装 diff → commit）の両方をここで一括承認する。
手順
Step 0. Pipeline status（必須・最初）
2 段構え。(a) と (b) は別の問いに答える — (a) は「いま承認するこの run は全段完走したか」、
(b) は「周辺ジョブは各自の締切までに成果物を出したか」。片方をもう片方の代わりにしない。
(a) 承認対象 run の完走確認（audit log が正）
承認する packet の {end-date}（weekly-{end-date}-packet.md）を使い、
$MOLTBOOK_HOME/logs/weekly-pipeline-audit.jsonl から当該 run の全 stage_result と
chain_end を確認する（run_id は weekly-{end-date}-HHMMSS 形式。同一週の再実行が
ありうるので最新 run_id を採る）:
python3 - "${MOLTBOOK_HOME:-$HOME/.config/moltbook}/logs/weekly-pipeline-audit.jsonl" {end-date} <<'EOF'
import json, sys
path, end_date = sys.argv[1], sys.argv[2]
events = [json.loads(l) for l in open(path)]
prefix = f"weekly-{end_date}-"
run_ids = sorted({e["run_id"] for e in events if e.get("run_id", "").startswith(prefix)})
if not run_ids:
sys.exit(f"NO RUN for {end_date}: audit has no run_id {prefix}* (chain never started)")
run_id = run_ids[-1]
ev = [e for e in events if e.get("run_id") == run_id]
extra = f" (earlier attempts: {', '.join(run_ids[:-1])})" if len(run_ids) > 1 else ""
print(f"run_id: {run_id}{extra}")
bad = []
for e in ev:
if e["event"] == "stage_result":
note = f" reason={e['reason']}" if e.get("reason") else ""
print(f" stage {e['stage']}: {e['result']}{note}")
if e["result"] != "ok":
bad.append(f"stage {e['stage']}={e['result']}")
end = [e for e in ev if e["event"] == "chain_end"]
if end:
print(f" chain_end: {end[-1]['result']} reasons={end[-1].get('reasons', '-')}")
if end[-1]["result"] != "ok":
bad.append(f"chain_end={end[-1]['result']}")
else:
bad.append("chain_end MISSING (run died mid-chain)")
print("VERDICT:", "PRESENT BEFORE DECIDING -> " + "; ".join(bad) if bad else "run completed clean")
EOF
chain_end が無い（途中死）、または result != ok の stage がある場合は、承認より先に
該当行をユーザーに提示する。skipped / reused は fail-forward の正常系でもある
（例: improve skipped reason=NO_RECURRENCE）— reason code とともに提示し、packet の
空欄が「対象なし」なのか「生成失敗」なのかを packet 冒頭の reason codes と照合して切り分ける。
(b) 周辺ジョブ（distill / insight / backup）
$MOLTBOOK_HOME/reports/PIPELINE-STATUS.md を読む。❌ があれば承認より先に
ユーザーに提示する。
誤読注意: PIPELINE-STATUS.md の weekly 系 2 行（weekly-report / weekly-packet）は、
土曜午前（締切 Sat 12:00 / 13:00 より前）は前週の成果物を映すのが正常。watchdog の
anchor_sat()（scripts/pipeline_watchdog.sh:76-82）は締切前は前週を anchor する設計で、
status が答える問いは「各ジョブは締切までに成果物を出したか」— 当日 run の完走は
答えない。「✅ ばかりだから当日 run も健全」と読まないこと（当日 run の完走は (a) のみが正）。
Step 1. Packet の提示
最新の $MOLTBOOK_HOME/reports/analysis/weekly-*-packet.md（引数があればその週）を読み、
Decision inventory をそのまま提示する（件数とスコープの明示列挙 — human-gate.md の
1 作業 1 ゲート）。以降、区分ごとに人間の判断を仰ぐ。
Step 2. Code patches（意図の要約 + reviewer verdict で判断）
packet の fix 表を提示（finding ID・attempts・Verify 結果・reviewer verdict）。
diff 本文は求められない限り出さない（human-gate.md: 実装コードは意図の要約）。
承認されたものについて:
git apply --check <patch> — 失敗（stale）なら defer: 理由を記録して飛ばす。
このセッションで再実装しない（実装者と承認者の分離）- 全承認 patch を apply したら、repo で Verify を再実行
（
uv run ruff check src/ tests/ scripts/ → uv run lint-imports → uv run pytest tests/ -q）
- 全 PASS で 単一 commit（1 Bash call = 1 git コマンド、git-workflow skill 準拠）。
commit message に採用 patch の finding ID を列挙。
plan との差分 の 3 値を宣言
- push は commit 後にユーザー確認の同じ承認セッション内で実施（main 直 push、branch/PR なし）
Step 3. Prompt diffs（本文全文で判断）
packet に inline されている prompt-scope diff を全文のまま提示（behavior-shaping
artifact — 要約に畳まない）。承認されたものだけ apply し、Step 2 と同じ commit に含める。
Step 4. Insight staging（adopt-staged は人間の承認で実行）
packet の推奨（RECOMMEND: adopt/reject + 理由）を item ごとに提示し判断を仰ぐ。
- 全件 adopt で合意 →
contemplative-agent adopt-staged --yes（audit には
stage-adopted-auto として残る）
- 部分採用 → per-item の監査記録は対話プロンプトが担うため、ユーザーに
ターミナルでの
contemplative-agent adopt-staged 対話実行を依頼する
（--yes は全件一括のみ。staging ファイルの直接削除は ADR-0012 の
auditable-CLI 原則に反するので行わない）
Step 5. Improvement proposal（あれば・本文全文で判断）
packet 6 節の pipeline 改善 diff を全文提示。採用なら pipeline 定義ファイルに apply し
Step 2 の commit に含める。却下なら理由を聞いて記録。
Step 6. Gate メトリクスの記録（必須・最後）
承認結果を集計して記録する（recommendation_matches = 機械推奨と人間判断が一致した件数）:
python3 scripts/build_decision_packet.py gate-record \
--metrics "$MOLTBOOK_HOME/logs/pipeline-metrics.jsonl" \
--end-date {end-date} \
--patches-adopted N --patches-rejected N --prompt-diffs-adopted N \
--insight-adopted N --insight-rejected N \
--recommendation-matches N --recommendation-total N
このレコードが翌週 packet の「F1 的中率」トレンドと、改善提案の発火判定の材料になる。
Out of scope（このセッションでやらないこと）
- 再診断・fix の再実装 — stale patch や CONCERNS verdict への対処は defer +
理由記録まで。作り直しは翌週のチェーンか、別途の通常実装セッションで行う
- 過去週 packet の一括処理 — 1 セッション 1 packet
- staging への書き込み（adopt-staged 以外の経路での操作）
