diff --git a/.takt/facets/instructions/review-todo-whole.md b/.takt/facets/instructions/review-todo-whole.md
index 9a093e5a..e48889d2 100644
--- a/.takt/facets/instructions/review-todo-whole.md
+++ b/.takt/facets/instructions/review-todo-whole.md
@@ -59,30 +59,24 @@ Check three things, in this order:
 1. **Landed-but-listed rows** — for each 順位 in the ledger's **active task tables only** (`### Batch 1` / `### Batch 2` under § 採用タスク (2), plus the § 採用タスク table when it is non-empty), `Grep` the exact table cell `| <順位> |` in `docs/todo-summary.md` / `docs/todo-summary2.md`. A row present in the ledger but **absent from both 順位 tables** has landed and should be removed (with the evidence recorded in the ledger's § 棚卸し履歴). Verify the task really landed (grep the artifact it claims to produce) before raising — a 順位 can also disappear because it was deprioritized.
 
    **Two scoping rules keep this from firing forever on correct content.** First, exclude the ledger's § 棚卸し履歴 and § 無人可としなかった…理由 tables: both carry 順位 columns, and 棚卸し履歴 deliberately retains already-removed 順位 as the audit record of *why* they were removed. Treating those as "listed" would raise the same finding every week for rows that are supposed to stay. Second, match the cell form `| <順位> |` rather than the bare number — a bare `120` also matches line counts, byte sizes, and other 順位 that merely contain those digits.
-2. **Promotion candidates** — 順位 rows in `docs/todo-summary*.md` that are **not yet listed** in the ledger and satisfy **either** promotion path the ledger accepts:
-   - § 採用タスク (2) の 3 基準 (verifiable by `cargo test --workspace`, no real Windows hook / `pnpm push` e2e, no cwd-dependent `#[ignore]` dependency), **or**
-   - § 採用タスク の 3 基準 (docs-only: edits confined to repo files, no Rust build / Windows hook / pnpm pipeline in the success condition, already adopted in the 順位 table).
+2. **Unlisted 順位 — report the count, do NOT judge eligibility** — state how many 順位 exist in `docs/todo-summary.md` + `docs/todo-summary2.md` that are not listed in the ledger's current task tables, so the user has a sense of the backlog the ledger does not cover.
 
-   The docs-only path currently has zero rows, but the ledger explicitly keeps it open for re-population, so a docs-only candidate that only the second path admits must still be surfaced. Name the 順位, which path it takes, and which criterion you checked. Do not propose promotion on title alone — read the detail entry.
+   **Judging which of them belong in the ledger is NOT this facet's job, and neither is proposing a `無人可` mark.** Under the lane model (ADR-072 決定 18) the ledger is an *assignment table*: listing a 順位 and setting its lane (`✅` = nightly loop / `—` = human) are both human decisions. The previous instruction demanded a full eligibility judgment of every unlisted 順位 with a two-path reason for each, and it failed on two consecutive runs (2026-08-13: ~50 of 164 sampled; 2026-08-15: 13 of 251 judged — both reported "0 candidates"). That obligation is withdrawn rather than re-strengthened a third time.
 
-   **Build the candidate set by exclusion, then judge ALL of it — never sample.** Take every 順位 in `docs/todo-summary.md` + `docs/todo-summary2.md`, then remove (a) 順位 already listed in the ledger's current task tables and (b) 順位 recorded in the ledger's **§ 昇格検査履歴** (previously examined and found ineligible). Judge every remaining 順位. The 2026-08-13 run judged "~50 recent / Tier 2 entries" out of 164 and reported zero — that is a sampled answer presented as a complete one, and it is exactly what the exclusion list exists to prevent. If the remaining set is large, say so and judge it anyway; do not silently narrow it.
+   **Counting only.** Report: total 順位 per summary file, how many are already listed in the ledger, and the remainder. If you happen to notice a specific 順位 that looks like an obvious fit, you may name up to a few as *examples* — clearly marked as examples, never as a screened set.
 
-   **A "zero candidates" conclusion is only valid if you judged the whole remaining set.** Otherwise report how many you judged and how many you did not, and treat the unjudged remainder as unknown rather than as ineligible.
+   **This section is still MANDATORY: `## 昇格候補 (promotion candidates)`.** Its content is now the count above; a missing section is still read as "check not performed" by `/weekly-review`.
 
    **When enumerating todo files, restrict to numbered detail files (`todo<数字>.md`) and expand range notation before comparing.** A bare `docs/todo*.md` glob also matches `docs/todo-summary.md` / `docs/todo-summary2.md`, which are 順位 tables rather than entry destinations; and the preamble writes ranges (`todo3.md 〜 todo23.md`, `todo3-23.md`) that never match as literal strings.
 
-   **This check is MANDATORY and its result must appear as a dedicated report section `## 昇格候補 (promotion candidates)` — even when the answer is zero.** A report without this section is treated as "check not performed", not as "no candidates" — the 2026-08-13 run silently skipped this exact check while completing every other criterion, and the omission was only detectable by a human re-reading the report. The mandatory section is the machine-checkable proof of execution.
+   > **This count will move to a deterministic step.** PR-5 of the lane-model work plan computes the same set difference in Rust (`lib-ledger` + the 順位-table parser) and feeds it to the weekly-review workflow. When that lands, this item becomes a pointer to that output and the counting stops being an LLM task.
+3. **`✅` rows whose 注意 column no longer reads as unattended-ready** — re-read the 注意 text of each `✅` row against conditions 1 and 2 of the ledger's § 自律実行可否の 2 段階分類 (no 「再選定」「着手時判断」「見積り」「検討」 or equivalent; implementation uniquely determined). A row edited since the lane was assigned may now carry a judgment the human who set `✅` never saw. Report it as **material for the human's lane decision**, not as a verdict.
 
-   The section must report, in this order: total 順位 from each summary file; how many were excluded as already listed in the ledger; how many were excluded via § 昇格検査履歴; **how many remained and how many of those you actually judged** (these two numbers must be equal — if they are not, the check is incomplete and must say so); and for each candidate found, the 順位, which promotion path it takes, and which criterion you verified. Also list the 順位 judged ineligible this cycle **with a one-line reason each that covers BOTH promotion paths** — the paths are OR'd, so ineligibility is only proven when each path either fails a named criterion (`docs-only 基準 1–3` / `cargo-test 基準 1–3`, per the ledger's § 昇格検査履歴 書式規約) or is stated inapplicable with why. A reason citing only one path (e.g. `cargo-test 基準 2 不適合` alone) cannot be recorded: it would permanently exclude a 順位 the other path still admits. The `/weekly-review` skill records these into § 昇格検査履歴 so future runs stop re-examining them; the ledger's re-evaluation on criteria changes filters by these numbers, so a reason leaving either path unaddressed makes the skill treat that 順位 as unjudged.
+   **Do NOT scan remote bookmarks or in-flight PRs for duplicate work.** Condition 3 (重複の恐れがない) was abolished on 2026-08-16 — it read the same `claude/nightly-<順位>` branch that ADR-072 決定 3 reads as "already in progress, skip", and the two readings contradicted each other. Under the lane model, duplication is prevented by *not making conflicting assignments* (a human taking over a task moves its lane to `—`), not by detection. A duplicate-detection finding raised here is out of scope and will be rejected.
 
-   **For each candidate, also quote verbatim any judgment-reserving wording found in its detail entry** —「再選定」「着手時判断」「見積り」「検討」 and phrasing to the same effect (options left open, estimates pending, human-decides-later). The skill transcribes these quotes into the ledger's 注意 column, and condition 1 of the 無人可 judgment scans **only that column** — wording dropped from your report is invisible to every later check, making a still-ambiguous task look unattended-ready. **When the quoted wording contains none of the four canonical keywords, prefix it with the canonical tag `「着手時判断: <原文>」`** — the condition-1 scan sees only those keywords, so an untagged synonym (「未定」「複数案あり」…) would be transcribed yet still slip through the scan (ledger § 自律実行可否の 2 段階分類 の転記規則). Report「判断留保の記述なし」explicitly when the detail entry contains none, so an empty 注意 cell is a verified fact rather than an omission.
-3. **無人可 marks that no longer hold** — this is the check nothing else can perform, because it depends on state **outside the corpus**. For every row marked `✅ 無人可`, confirm condition 3 of the ledger's § 自律実行可否の 2 段階分類 (no duplicate work in flight): use `jj log` and remote bookmark inspection to look for an unmerged branch or in-flight PR implementing the same task. A mark whose task now has an implementation branch must be raised — the nightly loop would otherwise duplicate it. Also re-read the row's 注意 column against conditions 1 and 2 (no 「再選定」「着手時判断」「見積り」「検討」; implementation uniquely determined); a row whose 注意 text has been edited since marking may no longer qualify.
+Severity guidance for this criterion: landed-but-listed rows are `low`–`medium` (ledger noise, but they can send the nightly loop at a finished task); a `✅` row whose 注意 column now carries judgment-reserving wording is `medium` (the lane may need revisiting, but a human decides).
 
-   **Absence of evidence is not evidence of absence here.** Unlike Criterion 0/1/2, this check reads state outside the repository (remote bookmarks, PR status), which can be unreachable — no network, no `gh` auth, a shallow or non-colocated clone. If you cannot actually observe remote/PR state, report condition 3 for that row as **unverified** and say which lookup failed. Do **not** write it up as "no duplicate found": a silent downgrade from "could not check" to "checked, clean" is exactly how a stale mark survives into the nightly loop. Reporting unverified is the correct advisory-layer behavior — this facet blocks nothing, so the cost of saying so is one line in the report.
-
-Severity guidance for this criterion: a stale `✅ 無人可` mark is `high` (it can cause an unattended agent to do conflicting or duplicate work); an **unverified** condition 3 is `medium` (the mark may be fine, but nobody has confirmed it this cycle); landed-but-listed rows and missing promotions are `low`–`medium` (ledger noise).
-
-**Do not propose adding or removing a `✅ 無人可` mark yourself as a settled decision** — the ledger states the marks are set by a human (ADR-022). Raise the finding with evidence and let the `/weekly-review` adoption step carry it to the user.
+**Never propose adding or removing a `✅` mark yourself as a settled decision** — lanes are assigned by a human (ADR-022, ADR-072 決定 18). Raise the material with evidence and let the `/weekly-review` adoption step carry it to the user.
 
 ## Calibration
 
@@ -93,7 +87,7 @@ If a finding needs natural-language judgment about task intent (「これはも
 ## Judgment procedure
 
 1. Glob the corpus + read the `docs/todo.md` preamble (routing contract).
-2. For Criterion 0/1/2, gather evidence with `Grep` / `jj log` — never raise a corpus-decay finding without a verified pointer. For Criterion 3, that is not enough: its condition 3 lives outside the repository, so you must additionally inspect **remote bookmarks and in-flight PRs** (`jj bookmark list --all-remotes`, `gh pr list`, or an equivalent lookup). If that lookup is unavailable, report the row's condition 3 as `unverified` and name the failed lookup — never as "no duplicate".
+2. Gather evidence with `Grep` / `jj log` — never raise a corpus-decay finding without a verified pointer. Every criterion, Criterion 3 included, is answerable from repository contents alone; no remote bookmark or PR lookup is required (or wanted — see Criterion 3-3).
 3. For each finding, articulate: what it is, where it lives (file + entry title/順位), the verifying evidence, and the proposed action (remove / merge / re-route / re-number).
 4. Classify each finding by severity (`critical` / `high` / `medium` / `low`) per ADR-031 § Findings スキーマ. Todo-hygiene findings are typically `low`–`medium` (corpus noise, not production risk); reserve `high` for a duplicate that could cause conflicting work.
 5. Write the report per the output contract (`review-todo-whole.md`). End with `analysis complete`.
@@ -102,7 +96,7 @@ If a finding needs natural-language judgment about task intent (「これはも
 
 - File: `review-todo-whole.md` (Report Directory)
 - Format identifier: `review-todo-whole`
-- **Required section**: `## 昇格候補 (promotion candidates)` must always be present (Criterion 3-2). Zero candidates → state 0 件 with the examination summary. The `/weekly-review` skill reads this section to drive the mandatory ledger-addition step; a missing section is reported to the user as "check not performed" (never silently treated as 0 件).
-- Read-only (`edit: false`): report findings only; the `/weekly-review` skill + user decide adoption (never edit `docs/todo*.md` or `docs/claude-code-web-tasks.md` from this facet — the ledger's 無人可 marks in particular are a human decision).
+- **Required section**: `## 昇格候補 (promotion candidates)` must always be present (Criterion 3-2). Its content is the **count of unlisted 順位**, not a screened candidate set — see Criterion 3-2 for what to report and what not to judge. A missing section is reported to the user as "check not performed" (never silently treated as 0 件).
+- Read-only (`edit: false`): report findings only; the `/weekly-review` skill + user decide adoption (never edit `docs/todo*.md` or `docs/claude-code-web-tasks.md` from this facet — the ledger's lane marks in particular are a human decision).
 - Category hint for aggregate-weekly: use `todo-dead-entry` / `todo-duplicate` / `todo-preamble-drift` / `ledger-staleness` (aggregate normalizes into the ADR-031 category set).
 - If nothing survives evidence-gathering, output「特筆すべき todo-hygiene の findings なし」and end with `analysis complete` (do not manufacture findings).
diff --git a/docs/adr/adr-033-todo-numbering-simplification.md b/docs/adr/adr-033-todo-numbering-simplification.md
index 86f7b544..754a4c1f 100644
--- a/docs/adr/adr-033-todo-numbering-simplification.md
+++ b/docs/adr/adr-033-todo-numbering-simplification.md
@@ -2,7 +2,9 @@
 
 ## ステータス
 
-試験運用 (2026-04-29)
+試験運用 (2026-04-29、2026-08-16 に「順位 = 追記型 ID」を明文化し再採番を廃止 → § 改訂)
+
+> **本文中の「再採番」は文脈で読み分けること。** § コンテキスト・§ 検討した選択肢・§ 決定 は**起票時点の記録**で、当時の前提 (再採番は起こりうる通常運用) をそのまま残す。現行の運用は**再採番をしない**であり、その決定と理由は § 改訂 (2026-08-16) が持つ。
 
 ## コンテキスト
 
@@ -73,9 +75,9 @@ table と本文を **同じ識別子で結合** していることが線形コ
 
 - 推奨実行順序サマリー table の `順位` 列が **唯一の絶対番号の source of truth**
 - 表の `依存` 列は絶対番号を許可 (例: `6, 8, 10`)。表内なので renumber と同期可能
-- それ以外の本文中で `順位 N` 表記を **使用禁止**
+- ~~それ以外の本文中で `順位 N` 表記を **使用禁止**~~ → **緩和 (2026-08-16)**。再採番を廃止したため本文参照は drift しない。§ 改訂 の指針に従う (タスク名を第一・順位の併記は可・削除済み順位への参照は残さない)
 
-#### 2. 本文での参照はタスク名で行う
+#### 2. 本文での参照はタスク名で行う (2026-08-16 以降は「タスク名を優先する」)
 
 - entry の heading text (例: `### Markdown 非 ASCII GFM アンカー検出 lint rule (PR #89 T1-1)`) を参照アンカーとして使う
 - 略称が定着しているものはそれを使う (例: `ADR-032 PR-β`、`Markdown linter hook 統合`)
@@ -102,20 +104,67 @@ table と本文を **同じ識別子で結合** していることが線形コ
 3. 新規 entry の template も同 PR で文書化 (本 ADR 内 or 別 section)
 4. 派生プロジェクト (techbook-ledger / auto-review-fix-vc) への展開は **後日独立 PR で対応** (本 PR スコープ外)
 
-### 検証ルール
+### 検証ルール — **撤回 (2026-08-16)**
 
-migration 完了の判定:
+> 起票時は下記 grep が 0 行になることを migration 完了の判定にしていた。**この検証は撤回する** — 本文の順位参照を禁止する規約自体を § 改訂 (2026-08-16) で緩和したため、0 行であることはもはや達成すべき状態ではない。実測 340 箇所という乖離は、規約が守られなかったのではなく**規約が不要だった**ことの証拠として読む。
+>
+> ```sh
+> # (撤回済み) 推奨実行順序サマリー table の外側で `順位 X` が使われていないこと
+> grep -nE "順位 [0-9A-Za-z_-]+" docs/todo*.md \
+>   | grep -vE "推奨実行順序サマリー|^[^:]+:[0-9]+:\| [0-9]+ \|"
+> ```
 
-```sh
-# 推奨実行順序サマリー table の外側で `順位 X` (数値・英字 placeholder 含む) が使われていないこと
-grep -nE "順位 [0-9A-Za-z_-]+" docs/todo*.md \
-  | grep -vE "推奨実行順序サマリー|^[^:]+:[0-9]+:\| [0-9]+ \|"
-# 期待: 0 行 (table 列以外で `順位 X` が使われていない)
-# 注: 数値だけでなく英字 placeholder (例: `順位 X`、`順位 N`) も検出対象。
-# ADR の本文中で「絶対番号を示唆する placeholder を本文に書かない」方針を機械検証する。
-# todo*.md は今後追加されうるため glob で全件対象 (本 ADR land 時は todo.md/2/3 のみだったが、
-# todo4-9 等が後から追加されており、hardcode list は stale 化する構造的問題を回避)。
-```
+## 改訂 (2026-08-16): 順位は追記型 ID であり、再採番はしない
+
+### 実測した運用の実態
+
+起票から約 4 か月の運用を実測したところ、**本 ADR が前提にしていた「再採番」は一度も起きていなかった**。
+
+| 観測 | 実測値 |
+|---|---|
+| 順位の並び | `docs/todo-summary.md` + `todo-summary2.md` を通して厳密な昇順、約 250 行 |
+| 欠番 | 多数 (`6, 10, 16, 17, 18, 28…` / 最大 461)。完了削除の跡 |
+| Tier 列 | 順位の昇順と**無相関**に混在 (Tier 1 と Tier 3 が隣接する) |
+| 再採番の実績 | **なし**。2026-08-12 に発見された孤児エントリ 4 件も、末尾に 433-436 を採番して解消している |
+| 本文中の `順位 N` 参照 | **340 箇所** (本 ADR が「例外なし」で禁止していたにもかかわらず) |
+
+つまり実態は「**順位 = 追記型の ID**、**優先度の実体は Tier 列**」であり、起票時の前提 (「絶対番号 = table のソート順」「全行が再採番される (本質的)」) は成立していない。**設計は既に正しく動いており、文書だけが古かった。**
+
+### 決定
+
+1. **順位は追記型 ID である。** 割り当ては常に「既存の最大 + 1」。欠番は埋めない
+2. **優先度は Tier 列が表す。** 行の並びは登録順であって優先度順ではない
+3. **再採番はしない**
+4. 細粒度の順序が必要になったときは、**行の並びで表す** (下記)。新しい採番体系も順序専用ファイルも作らない
+5. 列名「順位」と「推奨実行順序サマリー」という名称は**変えない**。パーサ・regex・ブランチ名規約・本文 340 箇所へ波及するため、**表記はそのまま・意味論だけ再定義**する ([ADR-072](adr-072-nightly-todo-loop.md) 決定 18 が `無人可` 列に対して採った手口と同じ)
+
+### なぜ再採番しないのか — データ整合ではなく自律実行の安全性
+
+順位は既に**識別子として**次の場所に埋まっている。
+
+| 埋め込み先 | 再採番したときに起きること |
+|---|---|
+| **`claude/nightly-<順位>` ブランチ名** ([ADR-072](adr-072-nightly-todo-loop.md) 決定 3・19) | **最も危険**。ブランチ存在で「着手済み / 人間確認待ち」を判定しているため、in-flight のマーカーが**別のタスクを指す**。夜間ループが無関係な順位を飛ばし、確認待ちのタスクを再実装しうる |
+| 台帳 `docs/claude-code-web-tasks.md` の順位列 | 別ファイルなので同時更新が要る。片方だけ更新すると選択元が壊れる |
+| `src/lib-ledger`（`removal.rs` / `rank_lookup.rs`）・`cli-ledger-cleanup` | 行を順位でしか引けないため、実行中の状態と食い違う |
+| summary の `依存` 列 / `cli-docs-lint` の priority_inversion | 参照の総書き換えが必要 |
+| 詳細エントリ本文の 340 箇所 | 追随漏れが drift になる (本 ADR の起票動機そのもの) |
+
+**再採番は表の整形ではなく、実行中の自律動作の意味を書き換える操作である。** 起票時にこの区別が無かったのは、当時まだ順位を読む自動化が存在しなかったためで、非難すべき見落としではない — **識別子は、それを読む機械が増えた瞬間に性質が変わる**。
+
+### 細粒度の順序が要るときは行の並びで表す (前例あり)
+
+`docs/claude-code-web-tasks.md` の Batch 表が既にこの形である — **行の並びが優先順位 (工数昇順)、順位列は ID として同居**しており、夜間ループはその行順の先頭を取る ([ADR-072](adr-072-nightly-todo-loop.md) 決定 1)。差し込みは 1 行挿入で済み、既存行に一切影響しない。
+
+順序を細かく表現したい表はこの形に倣う。**順序専用の別ファイルは作らない** — source of truth が 2 つになり、どちらかが必ず drift する (整合検査を機械化しない限り検出できず、instruction 層の義務は守られないことが実証済み)。
+
+### 帰結: 本文の順位参照の禁止を緩和する
+
+禁止規約の動機は「再採番したとき本文参照が drift する」の予防だった。**再採番しないと決めた以上、本文の `順位 N` は腐らない参照になる**ため、禁止を維持する根拠が消える。
+
+- **緩和後の指針**: 本文での参照は**タスク名を第一とする** (読み手が表と往復しなくて済む、という本 ADR 元来の利点は残る)。補助として `順位 N` を併記してよい。**削除済み順位への参照だけは残さない** (順位は再利用しないため、消えた番号は恒久的な dead pointer になる)
+- **禁止から緩和へ変えた対象**: § ガイドライン 1・2、§ アンチパターン「本文中の番号参照を「許容」してはならない (例外なし)」、§ 検証ルール (撤回済み)
+- **既存 340 箇所の一括修正は不要**。修正すべきは削除済み順位を指す参照だけで、それは通常の docs 保守で足りる
 
 ## priority table 運用ルール (PR #111 post-merge-feedback で追加)
 
@@ -184,9 +233,15 @@ table の `依存` 列を `順位 6` → `Phase pre` のようにタスク名に
 
 選択肢 A で却下したように、script 保守コストが新たな負債になる。table 1 行追加のみで済む規律で十分。
 
-### 本文中の番号参照を「許容」してはならない (例外なし)
+### ~~本文中の番号参照を「許容」してはならない (例外なし)~~ → 撤回 (2026-08-16)
+
+> 起票時は「例外を許すと徐々に元の状態に回帰する」として本文中の `順位 N` を 0 に保つよう定めていた。**この禁止は撤回した** — 回帰が問題になるのは再採番によって参照が腐るからで、再採番を廃止した以上その害が無い (§ 改訂)。実測 340 箇所という乖離も、規律の失敗ではなく**禁止の根拠が最初から弱かった**ことの証拠として読む。
+>
+> **ただし § 改訂 の指針は残る**: 参照はタスク名を第一とし、削除済み順位への参照は残さない。
 
-「ここだけ便利だから順位 N で参照したい」という例外を許すと、徐々に元の状態に回帰する。**移行後は本文中の `順位 N` 使用を 0 に保つ**。
+### 削除済みの順位を本文から参照してはならない
+
+順位は再利用しない (欠番を埋めない) ため、削除された順位への参照は**恒久的な dead pointer** になる。タスクを完了・撤回して行を消すときは、その順位を指す本文参照も同時に処理すること。
 
 ## 影響
 
@@ -199,14 +254,16 @@ table の `依存` 列を `順位 6` → `Phase pre` のようにタスク名に
 
 ### Negative
 
-- **既存 entry の参照表記の一斉変更**: 本 PR で 30+ 箇所の本文を書き換える必要がある (ただし mechanical な変換)
-- **新規 entry 記法のルール周知**: AI / 人間が新規 entry を追加する際に、本文に `順位 N` を書かないルールを守る必要がある (template で誘導)
-- **派生プロジェクトとの分岐**: 本リポジトリで先行採用した場合、派生プロジェクトの todo.md は旧形式のまま残るため、別 PR で同期が必要
+> **本節は起票時 (2026-04-29) の評価である。** 下記のうち上 2 点は本文の順位参照を禁止することの代償として挙げたもので、**§ 改訂 (2026-08-16) で禁止を緩和したため失効している** — 一斉変換も、書かないルールの周知も、もはや不要である。記録として残す。
+
+- ~~**既存 entry の参照表記の一斉変更**: 本 PR で 30+ 箇所の本文を書き換える必要がある (ただし mechanical な変換)~~ → 失効
+- ~~**新規 entry 記法のルール周知**: AI / 人間が新規 entry を追加する際に、本文に `順位 N` を書かないルールを守る必要がある (template で誘導)~~ → 失効
+- **派生プロジェクトとの分岐**: 本リポジトリで先行採用した場合、派生プロジェクトの todo.md は旧形式のまま残るため、別 PR で同期が必要 (この 1 点は現在も有効)
 
 ### 将来の展望
 
 - **派生プロジェクトへの展開**: 本 ADR の有効性を 1〜2 PR で確認後、派生プロジェクトにバックポート
-- **template の自動 lint**: 新規 entry が本文に `順位 N` を含むケースを pre-push hook で検出する custom_lint_rule を追加検討 (ADR-007 拡張)
+- ~~**template の自動 lint**: 新規 entry が本文に `順位 N` を含むケースを pre-push hook で検出する custom_lint_rule を追加検討 (ADR-007 拡張)~~ → **不要になった (2026-08-16)**。§ 改訂 で本文参照の禁止を緩和したため、検出すべき違反が存在しない。この展望から起票されていた順位 334 は同日 retire した
 - **entry 追加自動化**: skill / takt から todo entry を直接追加する経路ができた場合、本ガイドラインを template 反映する
 
 ## 新規エントリ template
@@ -218,7 +275,7 @@ table の `依存` 列を `順位 6` → `Phase pre` のようにタスク名に
 
 > **動機**: <既存の問題、or 機会>。
 >
-> **本タスクの位置づけ**: <他 task / ADR との関係。`順位 N` 表記は使わず、タスク名で参照>。
+> **本タスクの位置づけ**: <他 task / ADR との関係。参照はタスク名を第一に、必要なら `順位 N` を併記>。
 >
 > **参照**: `.claude/feedback-reports/<N>.md` Tier <X> #<Y>
 >
@@ -251,7 +308,7 @@ table の `依存` 列を `順位 6` → `Phase pre` のようにタスク名に
 | <順位 N> | <Tier 絵文字 + ラベル> | <task name (PR #N T<X>-<Y>)> | <ファイル名> | <Effort> | <依存タスク名 or 順位 (table 内なら絶対番号 OK)> |
 ```
 
-`順位 N` の決定基準は本ガイドラインの Tier 別優先度ロジックに従う。本文中の他 entry に対する変更は不要。
+`順位 N` は **既存の最大 + 1** を末尾に付ける (§ 改訂 決定 1)。優先度は `Tier` 列で表すため、順位の値を優先度に合わせて選ぶ必要はない。既存行および本文中の他 entry に対する変更は不要。
 
 ## References
 
diff --git a/docs/adr/adr-052-autonomy-execution-boundary-classes.md b/docs/adr/adr-052-autonomy-execution-boundary-classes.md
index 135275e5..0b44d444 100644
--- a/docs/adr/adr-052-autonomy-execution-boundary-classes.md
+++ b/docs/adr/adr-052-autonomy-execution-boundary-classes.md
@@ -42,6 +42,8 @@ ADR-028 は「自律性（判断の複雑度）」と「外部可視性（取り
 | Tier 3 cleanup（todo taxonomy の 💎 Tier 3 = 低リスクな機械的 refactor / doc / rule / visibility scoping 等） | 意図表現を侵さない局所変更。revert 容易 |
 | `claude/` prefix ブランチへの push | trunk ではない隔離 namespace。ブランチ push は revert 可能で、まだ PR として外部にコミットされていない |
 | `claude/` ブランチからの **PR 作成**（draft / 非 draft を問わない = **autonomous-pr クラス**） | 「無人実装 → 人間レビューへの handoff 点」として設計上の停止地点になる。close は容易で、マージしない限り trunk に影響しない。**背圧（原則 5）の接続が有効化の前提条件** |
+| **自分が作った `claude/` ブランチの削除**（**PR が紐づくものに限る**。closed / merged を問わない） | `claude/**` 空間内で trunk に影響しない。PR があれば成果物と diff は PR 上に残り、GitHub の **Restore branch** で復元できる。PR が紐づく = 人間が close か merge かの判断を済ませたもの（[ADR-072](adr-072-nightly-todo-loop.md) 決定 20） |
+| **`claude/` 空間への空 ref の作成**（失敗マーカー） | 既存 commit を指す ref を 1 本増やすだけで、コードも PR も作らない。削除も復元も容易で、外部レビュー面には何も現れない（[ADR-072](adr-072-nightly-todo-loop.md) 決定 19） |
 
 #### ゲート必須クラス（人間の承認まで実行しない）
 
@@ -66,6 +68,16 @@ ADR-028 は「自律性（判断の複雑度）」と「外部可視性（取り
 >
 > **背圧の同時改訂**: 背圧の指標も「未マージ **draft** 数」から「未マージの `claude/` PR 数」へ変える必要がある（原則 5）。draft で数え続けると計数が常に 0 になり、**背圧が無音で無効化**される — 原則 5 が禁じる状態そのものなので、本改訂と分離して land させてはならない。
 
+#### 改訂（2026-08-16）— ref のライフサイクル操作を自動実行可へ加える
+
+[ADR-072](adr-072-nightly-todo-loop.md) の lane モデル（決定 18〜20）が、夜間ループに 2 つの新しい ref 操作を要求する — **決着済み PR のブランチの自動掃除**と、**失敗マーカーとしての空 ref 作成**である。自動実行可クラスの表へ 2 行を追加した。
+
+**どちらも commitment 点の侵犯には当たらない。** 判断の軸は原則 2 と同じ「取り消しコスト」で、ここでは*何が失われうるか*を見る。空 ref の作成は既存 commit への参照を 1 本増やすだけで、成果物も外部レビュー面も生まない。ブランチ削除は一見取り消しコストが大きいが、**対象を PR が紐づくものへ限る**ことで (a) 人間が close か merge かの判断を済ませている、(b) 成果物と diff は PR 上に永続、(c) GitHub の Restore branch で復元可能、の 3 点が揃う。
+
+**復元可能性は「PR が残っていること」に依存している。** したがって PR の無いブランチ（= 失敗マーカー）を削除対象に含めることは本改訂の範囲外であり、ADR-072 決定 20 が明示的に禁じている。**逆に merged PR のブランチは対象に含む** — 復元可能性の根拠は PR の存在であって close か merge かではなく、除外すると消し忘れたブランチが順位を永久に選択不能にする（同決定 20）。
+
+**一般則**: 自律 actor が自分で作った `claude/**` の ref を、自分が作った文脈の中で片付けることは自動実行可である。他者が作った ref、`claude/**` の外、あるいは成果物が他に残らない削除は、いずれも本行の範囲に入らない。
+
 ### 原則 3: 分類不能は fail-closed（ゲート必須に倒す）
 
 自動実行可クラスに**明確に該当しない**操作は、すべてゲート必須クラスとして扱う。分類関数の入力が `None` / `Err` / timeout 等で確定不能な場合も同様にゲート必須へ倒す（[ADR-043](adr-043-security-gates-fail-closed.md) 原則 1「判定不能はデフォルト blocking」）。「疑わしきは自動実行可ではない」（ADR-035 の「疑わしきは docs-only ではない」と同じ安全側デフォルト）。
@@ -145,5 +157,6 @@ ADR-028 は「自律性（判断の複雑度）」と「外部可視性（取り
 - [ADR-043](adr-043-security-gates-fail-closed.md)（fail-closed 原則）— 分類不能をゲート必須へ倒す既定の根拠
 - [ADR-039](adr-039-experimental-feature-standard-pattern.md)（試験運用標準パターン）— config opt-in + kill-switch + bounded lifetime
 - [ADR-019](adr-019-coderabbit-review-hybrid-policy.md)（CodeRabbit ハイブリッド構成）— 無料枠クォータの制約。2026-08-09 改訂前は「draft 除外 = quota 非消費」が draft PR を自動実行可とする根拠でもあった
+- [ADR-072](adr-072-nightly-todo-loop.md)（夜間 todo 消化ループ）— autonomous-pr クラスの実装。決定 18〜20 の lane モデルが 2026-08-16 の ref ライフサイクル改訂の要求元
 - `src/lib-docs-policy`（`is_docs_only_summary` — ADR-035 path 基準の単一実装。[ADR-057](adr-057-docs-only-deterministic-routing.md) で `gate.rs` から切り出し済、実装スコープ節の 2026-08-02 訂正を参照）— 分類関数の再利用母体
 - セッション 247510ea-3f24-4b87-8f68-3c860e1b1b4e（2026-04-18）/ PR #54 — 無ゲート自律実行の事故（ADR-028 と共有する反例）
diff --git a/docs/adr/adr-072-nightly-todo-loop.md b/docs/adr/adr-072-nightly-todo-loop.md
index 47370837..9cfedd2d 100644
--- a/docs/adr/adr-072-nightly-todo-loop.md
+++ b/docs/adr/adr-072-nightly-todo-loop.md
@@ -2,7 +2,7 @@
 
 ## ステータス
 
-試験運用 (2026-08-06、2026-08-09 に停止点を draft PR から通常 PR へ変更、2026-08-10 にレビュー要求経路を確立)
+試験運用 (2026-08-06、2026-08-09 に停止点を draft PR から通常 PR へ変更、2026-08-10 にレビュー要求経路を確立、2026-08-16 に担当管理を lane モデルへ移行 = 決定 18〜20)
 
 > [ADR-052](adr-052-autonomy-execution-boundary-classes.md) の自動実行可クラスのうち **PR 作成 (autonomous-pr クラス)** を、[ADR-066](adr-066-autonomy-global-kill-switch.md) の kill-switch と [ADR-071](adr-071-draft-pr-backpressure.md) の背圧の上に実装する。無人 fix push ([ADR-067](adr-067-phase-b-unattended-fix-push.md)) の次の段で、**自律 actor が初めて「新しい成果物」を作る**経路になる。
 >
@@ -446,6 +446,81 @@ public リポジトリでは **fork からの PR でも起動し、その時点
 
 **出力契約の allowlist にも足すこと**。`cli-nightly-task-select` の新出力 `pr_title_display` は、workflow の `grep -E '^(...)='` 許可リストと出力契約の検証の両方へ同時に足す必要がある。片方だけだと**新しい出力が黙って捨てられ、毎晩フォールバックし続ける**形で劣化する (workflow のコメントが警告していた失敗モードそのもの)。検証 step は `pr_title_display=` の**行の存在**を見る (値は空でもよい)。
 
+### 18. 台帳は担当割り当て表である — 無人可列を lane として再定義する (2026-08-16)
+
+**契機は、同じ事実を 2 つの規則が逆に解釈していたことである。** 決定 3 は `claude/nightly-<順位>` ブランチの存在を「着手済みマーカー = 再選択しない」と読む。一方、台帳 ([docs/claude-code-web-tasks.md](../claude-code-web-tasks.md)) の無人可判定条件 3 (重複の恐れがない) は、同じブランチを「未マージの実装が存在する = 無人可マークを外す理由」と読む。**一方は「そのまま進め」、他方は「マークを降格せよ」を導く。**
+
+この矛盾は実害を出した。2026-08-13 の週次レビューが条件 3 を根拠に 2 件の finding を出し、採用された。片方 (WR-2026-08-13-T01) は台帳の明文規定「削除するのはマージした順位だけ」と正面から矛盾しており、**実行すれば未完了タスク 3 件が台帳から静かに消える**ところだった (撤回の記録は [docs/todo.md](../todo.md) § 週次レビュー採用 と当該 PR description)。
+
+**根本は、「タスク割り振り」という問題を「分散システムの状態管理」として解いていたことにある。** ブランチ・PR・マージ履歴という GitHub 上の副作用から、誰が担当していて何が終わったのかを**推測**していた。推測の規則が 2 つあれば、いつか食い違う。
+
+**決定: 台帳が担当を直接表現する。**
+
+```text
+台帳 = 担当割り当て表
+  無人可列 ✅ = auto  (夜間ループに割り当て)
+  無人可列 —  = human (ユーザー + Claude Code に割り当て)
+```
+
+**表の形式は変えない。意味論だけを再定義する** — 列も記法も既存のまま、読み方を「着手してよいかの資格判定」から「誰の持ち物か」へ移す。
+
+帰結として、判定条件から**条件 3 を削除する**。条件 1 (着手時の判断が要らない) と条件 2 (実装内容が一意) は残るが、位置づけが変わる — **合格すれば自動で auto になる資格要件ではなく、人間が lane を割り当てるときに使う判断材料**である。条件 3 だけを消すのは、それが「台帳の外を見ないと判定できない」唯一の条件であり、週次棚卸しという不安定な機構を要求していたためでもある。
+
+**運用原則は 2 つに集約される。**
+
+- **lane の判断は人間だけが行う。** 夜間 worker は auto の先頭 1 件を取って実行するだけで、「本当に簡単か」「重複しないか」を再審査しない (決定 1 と [ADR-022](adr-022-automation-responsibility-separation.md) の責務分離を、担当管理の側から言い直したもの)
+- **競合は検出するのではなく、競合する割り当てをしない。** 人間が auto を付けたタスクは夜間ループの所有物である。人間が引き取るなら lane を human に変える。**検出ゲートは割り当て規律の代替にならない** — 検出は必ず取りこぼし、取りこぼした先が上記の「同じ事実の二重解釈」になる
+
+### 19. ブランチは作業中マーカー — agent 実行後の停止は空 ref を残して人間確認へ (2026-08-16)
+
+**ブランチ (`claude/nightly-<順位>`) は作業中マーカーであって完了マーカーではない。** 完了を表現するのは、PR に同梱された台帳行の削除 (`cli-ledger-cleanup --apply`) がマージされることだけである。決定 3 は除外の実装としてブランチ存在を使っているが、それは「誰かが手を付けた」以上の意味を持たない。
+
+**この区別が無いと、失敗した run が先頭を独占する。** verify 段で落ちた run はブランチも PR も残さないため、翌晩まったく同じタスクが再選択される。無人ループは毎晩同じ場所で同じ失敗を繰り返し、後続のタスクへ進まない。
+
+**決定: implement 完了後に publish へ到達しなかった run は、空 ref を作って停止する。**
+
+対象は **verify 失敗 / ledger-completion 未完了 / guard deny / 空 diff**。agent 起動前に記録済みの base commit (`git -C work rev-parse HEAD`) を指す ref `claude/nightly-<順位>` を `gh api -X POST /repos/{owner}/{repo}/git/refs` で 1 回作る。**コードは push しない** — 完遂できなかった成果物を人間のレビュー面へ出す意味はなく、必要なのは「この順位は人間の確認待ちである」という 1 ビットだけである。
+
+マーカーがある限り決定 3 の除外 (`git ls-remote` によるブランチ存在確認) がそのまま効くため、**selector 側の変更は要らない**。run の色は決定 10 に従い green のままだが、`[NIGHTLY_SKIP]` とは**別のマーカー** (`[NIGHTLY_HANDOFF]`) で `Report outcome` に出す — 「何もすることが無かった夜」と「人間の確認が要る夜」を run 一覧で区別するためで、決定 10 が色でやったことを、同じ色の中でもう 1 段分けている。
+
+**implement より前の停止はマーカーを作らない。** kill-switch / 背圧 deny / タスク無し / インフラ障害 (network / gh / clone) はいずれも agent が走る前に決着するため、翌晩そのまま再試行されるのが正しい。
+
+**この境界が、失敗理由の分類を構造で代替する。** 「transient な障害か、タスクそのものが不適合か」を判定する分類器は作らない — インフラ障害は構造上 implement へ到達せずマーカーを残さない。**run のどこで止まったかが、そのまま分類になっている。**
+
+### 20. 再投入は人間の明示操作 — 決着済み PR のブランチだけを自動掃除する (2026-08-16)
+
+**失敗したタスクを、無変更で自動再投入しない。** agent が完遂できなかったということは、台帳の記述・タスクの粒度・環境のいずれかに人間が見るべきものがある。同じ入力で再実行しても結果は同じで、消えるのは Max 枠だけである。
+
+**再投入の意思表示は台帳とブランチの 2 操作で表す。**
+
+| 人間の意図 | 操作 |
+|---|---|
+| 引き取る (人間が実装する) | 台帳の `✅` を `—` へ変更し、マーカー / ブランチを削除 |
+| 仕様を直して再投入する | `✅` のまま、マーカー / ブランチを削除 |
+
+**決着済み PR のブランチは自動で掃除する。** 夜間ループはタスク選択の**前**に、`claude/nightly-*` のうち紐づく PR がすべて決着済み (**closed または merged**) のものを削除する。close は「この成果物は採らない」、merge は「取り込んだ」という判断がそれぞれ済んでおり、どちらもブランチを残す理由が無い。
+
+**merged を除外しない。** 初版は「merged は通常ブランチ削除済み」として対象外にしていたが、これは**運用に依存した仮定**であり、外すと穴が開く — マージ時にブランチが消し忘れられ、かつ台帳の行が残っている場合 (台帳 § 未完了のままマージされた順位 が記録する実在の失敗モード)、そのブランチは決定 3 の除外を効かせ続け、**その順位は誰にも気づかれないまま永久に選択されなくなる**。closed と merged を分けない方が規則も単純になる ([#409](https://github.com/aloekun/claude-code-hook-test/pull/409) の CodeRabbit 指摘)。
+
+**PR の無いブランチは削除しない。** それは決定 19 の失敗マーカーであり、掃除すると人間の確認を待たずに再投入される。**したがって境界は「PR があるか」の 1 点だけ**になる — PR があれば掃除、無ければ残す。判定は `cli-stale-branch-scan` が既に持つ規則 (「PR が 1 件も無いブランチは提案対象外」) をそのまま使う。**shell で PR 状態をパースしない** — 決定 1 が選択ロジックを exe に置いたのと同じ理由で、回帰テストの場が無い判定を無人経路に置かない。
+
+したがって **lane を auto のまま close する = 再投入の意思表示**になる。掃除がブランチを消し、翌晩の選択で同じ順位が再び候補に入る。この含意は人間が close 画面で思い出せないと機能しないため、nightly PR の body テンプレートに 1 行の案内を入れる。
+
+**削除は App token で行う** (job の `GITHUB_TOKEN` は決定 8 § 副次効果 により read-only)。掃除は選択前、失敗マーカーは verify 後なので、token の mint は job 冒頭と implement 後の 2 回になる (寿命 1 時間・agent 最大 60 ターンという決定 8 の制約は変わらない)。
+
+**自ブランチの削除と空 ref の作成が自律 actor の操作分類に加わる** — どちらも `claude/**` 空間に閉じ、closed PR のブランチは GitHub の Restore branch で復元できるため commitment 点の侵犯には当たらない ([ADR-052](adr-052-autonomy-execution-boundary-classes.md) § 操作分類に追記)。
+
+#### 検討して捨てた案 (決定 18〜20 の設計時、2026-08-16)
+
+| 案 | 捨てた理由 |
+|---|---|
+| `claude/nightly-state` ブランチに試行履歴を持ち、最終試行日の古い順に選ぶ | 自動再投入をやめた (決定 20) 時点で、試行履歴も選択順の変更も要らなくなった。**状態を持つ前に、状態が要らない設計にできないかを問う** |
+| 台帳の「対象ファイル」列の重なりを走査して他経路との重複を検出する | 決定 18 の「競合する割り当てをしない」が原則であり、検出は割り当て規律の代替にならない。ゲートを増やすほど、通った場合の「重複していない」という誤った確信が強くなる |
+| `Ledger-Rank` trailer を未マージブランチ全体から走査して重複を検出する | trailer は任意記入であり、実際に問題になった例 (順位 284 の `claude/select-next-task-a9aiam`) は trailer を持たない。**手で書く印を機械の判定根拠にしない** |
+| 失敗理由を transient / タスク不適合に分類する分類器 | インフラ障害は構造上 implement へ到達せずマーカーを作らない (決定 19)。**run の構造が既に分類しているものを、後段の判定器で作り直さない** |
+| タスク選択時に台帳へ試行日を直 push する (試行日列の新設) | 決定 6 のガード対象ファイルへ自律 actor が書き込む経路の新設にあたる。同型の案は [ADR-070](adr-070-weekly-review-cloud-routine.md) で却下済み |
+| 再挑戦上限 N 回 | 再投入が人間の操作になったため、回数を数える主体も置き場所も無くなった |
+
 ## 試験運用判断基準 (ADR-039)
 
 | 項目 | 内容 |
@@ -685,4 +760,3 @@ CodeRabbit の反応の中身は `Review limit reached` (レート制限、`Next
 - **authority gate の直前で自律 PR 数を再計数するか**。現状は job 冒頭のスナップショットを使い回す (§ 決定 4)。閾値を 1 件超えて push される事象が実運用で観測されたら入れる。**再計数を入れない現状の根拠**: 超過は最大でも 1 件で、背圧は「積み過ぎを止める」ためのものであって厳密な上限ではない。同一 workflow の並行 run は `concurrency` で直列化済みなので、増分の出所は別経路 (人手 / Phase B) に限られる。CodeRabbit の PR [#376](https://github.com/aloekun/claude-code-hook-test/pull/376) レビューが同じ点を指摘したが、この保留は意図であり指摘を受けての新規判断ではない。
 - **ガードレール禁止リストの allowlist 化**。台帳の「対象ファイル」列を機械可読にする (別列に正規化パスを持つ等) のが前提。
 - **禁止リストが YAML に埋まっている**。`cli-nightly-task-select` や専用 exe へ移せば unit test で固定できるが、現状は workflow step の `grep` で、回帰テストが無い。リストが育つようなら extract する ([ADR-044](adr-044-subprocess-utility-extraction-boundary.md) 層 1 の判断基準に従う)。
-- **失敗した run の学習が無い**。同じタスクで 3 晩失敗しても 4 晩目に同じことを試す。連続失敗の検出と自動除外は WP-19 ステップ 3 の監査ループで扱う。
diff --git a/docs/claude-code-web-tasks.md b/docs/claude-code-web-tasks.md
index 315c4b6f..5dfc6552 100644
--- a/docs/claude-code-web-tasks.md
+++ b/docs/claude-code-web-tasks.md
@@ -10,24 +10,38 @@
 
 本ファイルは 2026-08-06 から、Claude Code Web セッションの pickup scope に加えて**夜間 todo 消化ループ（WP-18）の選択元**を兼ねる。両者は必要な自律度が違うため、実行可否を 2 段階に分ける。
 
-| 段階 | 意味 | 前提 |
+| 段階 | 意味 | 決まり方 |
 |---|---|---|
 | **Web 実行可** | 人間が対話で補助できる前提で着手できる。曖昧な点はセッション中に確認して詰められる | 本ファイルの各表に載っていること自体がこの段階 |
-| **無人可** | 補助なしで完結する。実装内容が台帳の記述だけで一意に決まり、着手時の設計判断が要らない | 上に加えて下記 3 条件をすべて満たす |
+| **無人可 (= auto lane)** | そのタスクを**夜間ループに割り当てた**という表明。補助なしで完結すると人間が判断したもの | **人間が `✅` を付けたときにそうなる**。下記の判断材料を満たすことは自動的な昇格を意味しない |
 
-**無人可の判定条件**:
+**条件を満たすこと自体は `✅` を意味しない。** 下記は人間が lane を割り当てるときに使う**判断材料**であって、機械的に適用すると `✅` が決まる資格要件ではない (→ [§ 無人可列は担当割り当て（lane）である](#無人可列は担当割り当てlaneである2026-08-16adr-072-決定-18))。
+
+**lane 割り当ての判断材料**:
 
 1. **着手時の判断が要らない** — 台帳の「注意」欄に「再選定する」「着手時判断」「見積り」「検討」といった、人間が決める前提の記述がない
 2. **実装内容が一意** — 何をどこに書くかが台帳と対象ファイルの現物から決まる。設計の選択肢が複数残っていない
-3. **重複の恐れがない** — 同一タスクの実装が未マージのブランチや進行中の PR に存在しない
 
-3 は台帳だけでは判定できないため、定期棚卸し（→ § ライフサイクル）で確認する。**判定に迷ったら無人可にしない** — 誤って無人可にしたタスクは、夜間ループが人間の意図と違う実装で draft PR を作る形で失敗する。無人可にしなかったことによる損失は「Web セッションで人間が着手する」だけであり、非対称に軽い。
+**判定に迷ったら無人可にしない** — 誤って無人可にしたタスクは、夜間ループが人間の意図と違う実装で PR を作る形で失敗する。無人可にしなかったことによる損失は「Web セッションで人間が着手する」だけであり、非対称に軽い。
+
+**判断材料 1 の確認は「注意」欄のキーワード走査に依存する。** したがって本台帳へ行を追記する者（weekly-review skill の昇格追記を含む）は、詳細エントリ（`docs/todoN.md`）にある判断留保の記述 —「再選定」「着手時判断」「見積り」「検討」など人間が決める前提の語 — を要約で圧縮・省略せず「注意」欄へ転記しなければならない。転記が落ちると、詳細エントリでは判断が残っているタスクが台帳上は判断材料 1 を満たして見え、lane を割り当てる人間の目が構造的に塞がれる。
+
+転記する原文が上記の例示語をどれも含まない同義表現（「未定」「どちらでもよい」「複数案あり」等）の場合は、**正準タグを付して「着手時判断: <原文>」の形で転記する**。キーワード走査は例示語しか見ないため、タグ無しの同義表現は判断が残っているのに素通りする。
+
+### 無人可列は担当割り当て（lane）である（2026-08-16、[ADR-072](adr/adr-072-nightly-todo-loop.md) 決定 18）
+
+**本台帳は担当割り当て表である。** `無人可` 列は「自動化しても壊れないかの資格判定」ではなく、**そのタスクを誰が持っているか**を表す。
+
+| 列の値 | lane | 意味 |
+|---|---|---|
+| `✅` | **auto** | 夜間ループに割り当て済み。そのタスクは夜間ループの所有物 |
+| `—` | **human** | ユーザー + Claude Code に割り当て。夜間ループは触らない |
 
-**条件 1 の判定は「注意」欄のキーワード走査に依存する。** したがって本台帳へ行を追記する者（weekly-review skill の昇格追記を含む）は、詳細エントリ（`docs/todoN.md`）にある判断留保の記述 —「再選定」「着手時判断」「見積り」「検討」など人間が決める前提の語 — を要約で圧縮・省略せず「注意」欄へ転記しなければならない。転記が落ちると、詳細エントリでは判断が残っているタスクが台帳上は条件 1 を満たして見え、無人可判定（人間のマーク付与と週次レビューの再検査の両方）が構造的に盲目化する。
+上の判断材料 1・2 は、**人間が lane を割り当てるときに使うもの**であって、満たせば自動的に `✅` になる資格要件ではない。マークを付けるのは常に人間である（[ADR-022](adr/adr-022-automation-responsibility-separation.md) の責務分離）。**夜間ループは auto の先頭 1 件を機械的に取るだけで、「本当に簡単か」「他で誰かが実装していないか」を再審査しない。**
 
-転記する原文が上記の例示語をどれも含まない同義表現（「未定」「どちらでもよい」「複数案あり」等）の場合は、**正準タグを付して「着手時判断: <原文>」の形で転記する**。キーワード走査は例示語しか見ないため、タグ無しの同義表現は判断が残っているのに条件 1 をすり抜ける。
+**競合は検出するのではなく、競合する割り当てをしない。** `✅` を付けたタスクを人間が引き取るなら、着手する前に `—` へ変える。この規律が守られていれば重複は起こらず、守られていなければどんな検出ゲートも取りこぼす。
 
-マークは**人間が付ける**（ADR-022 の責務分離）。夜間ループは無人可マークの有無を機械的に読むだけで、自分でこの判定をしない。
+> **2026-08-16 に条件 3（重複の恐れがない = 同一タスクの実装が未マージのブランチや進行中の PR に存在しない）を廃止した。** 同じ `claude/nightly-<順位>` ブランチを、[ADR-072](adr/adr-072-nightly-todo-loop.md) 決定 3 は「着手済み = 再選択しない」と読み、条件 3 は「未マージ実装がある = マークを降格せよ」と読んでいた。同じ事実から逆の結論が出る状態が、誤った週次 finding（WR-2026-08-13-T01/T02、実行すれば未完了タスク 3 件が本台帳から消えるところだった）を生んだ。代替のゲートは設けない — 上記の割り当て規律がその役割を持つ。
 
 ## 採用タスク
 
@@ -65,7 +79,20 @@
 3. 詳細エントリが置かれた `docs/todoN.md` の該当 section を削除する
 4. そのうえで PR をマージし、ブランチも削除する
 
-**削除するのはマージした順位だけ。** クローズした夜間 PR の順位は**完了していない**ので本ファイルに残す。その場合はブランチが残る限り再選択されず、ブランチを整理した時点で再び選択対象へ戻る（[ADR-031](adr/adr-031-weekly-review-pipeline.md) § 残存ブランチ検出 が週次で棚卸しし、再挑戦は許容する方針）。
+**削除するのはマージした順位だけ。** クローズした夜間 PR の順位は**完了していない**ので本ファイルに残す。
+
+### 夜間 PR を close するときの lane 操作（2026-08-16、[ADR-072](adr/adr-072-nightly-todo-loop.md) 決定 20）
+
+close は「この成果物は採らない」という判断であって、「このタスクをやめる」とも「人間がやる」とも決まっていない。**どちらなのかを `無人可` 列で表明する。**
+
+| close 時の意図 | 操作 | その後 |
+|---|---|---|
+| **人間が引き取る** | `✅` を `—` へ変更する（ブランチ / 失敗マーカーがあれば削除） | 夜間ループは以後この順位を選ばない |
+| **仕様を直して再投入する** | `✅` のまま。ブランチ / 失敗マーカーを削除する | 掃除後に再び選択対象へ戻る |
+
+**`✅` のまま close する = 再投入の意思表示である。** 夜間ループは起動時に「決着済み (closed / merged) の PR に紐づく `claude/nightly-*` ブランチ」を自動で掃除するため、放置すると翌晩以降に同じ順位が再選択される。意図しない再実装を避けたいなら、close と同時に lane を `—` へ移すこと。
+
+**PR の無い `claude/nightly-<順位>` ブランチは掃除されない。** それは夜間ループが implement 後に停止したときの**失敗マーカー**（同決定 19）で、人間が確認するまでその順位は選択されない。確認後、上表のどちらかの操作で決着させる。
 
 ---
 
@@ -130,18 +157,18 @@ cargo test で検証完結するが、新規 module / lint rule / 軽微リフ
 |---|---|---|---|---|---|---|---|
 | 340 | T2 | — | `decide.rs` の rate_limit × positive-evidence 複合境界テスト + `main.rs` の rate_limit threading テスト | `src/check-ci-coderabbit/src/{decide,main}.rs` | S | (a) は純関数で容易。(b) は `main.rs` の呼び出し側を I/O 無しでテスト可能にする小さな合成関数抽出リファクタが要る |  |
 | 272 | T1 | — | cli-docs-lint に ADR 重複採番検出 + CLAUDE.md 索引整合チェック（新規 validator module） | `src/cli-docs-lint/src/adr_consistency.rs`（新規）+ `src/cli-docs-lint/src/main.rs`（CheckMode dispatch 拡張） | S-M | 中核（validator + fixture test）は cargo test で完結。「pnpm lint:docs 経由の発火確認」は Web 外だが成功条件ではない。CLAUDE.md は docs_dir の親なので TempDir で fake 構造を組む |  |
-| 334 | T1 | — | docs/todo\*.md 本文の順位番号表記を検出する custom lint rule（ADR-033 仕組み化、`paths=["docs/todo*.md"]` scope、table 行除外） | `.claude/custom-lint-rules.toml` + `tests/fixtures/incidents/{bad,good}/`（216 と同基盤） | M | 検証経路は 216 と同じ cargo test。**regex FP 精緻化**（preamble の「順位 220 以降」等）+ **本文 dogfood cleanup の規模**を着手前に grep 見積り（todo 記載 S だが M 見込み） |  |
 | 179 | T2 | — | rate-limit retry 境界（max_retries=0/1/3）で retry 継続 vs `action_required` 遷移の off-by-one を pin する parameterized テスト | `src/cli-pr-monitor/src/stages/poll/rate_limit.rs`（判定 L52）+ `src/cli-pr-monitor/src/config.rs`（L143-155） | S-M | **todo の「rstest 使用済」は誤り**（Cargo.lock に不在）。新 dev-dep 追加 or plain 複数 `#[test]` で代替を着手時判断。gh subprocess を踏まない早期 return 経路で構成する |  |
 
-### 無人可としなかった 7 件の理由
+### 無人可としなかった理由
+
+「注意」欄の記述と § 自律実行可否の 2 段階分類 の判定条件を突き合わせた結果。将来この判断を見直す際、根拠を再調査せずに済むよう残す。
 
-「注意」欄の記述と § 自律実行可否の 2 段階分類 の 3 条件を突き合わせた結果。将来この判断を見直す際、根拠を再調査せずに済むよう残す。
+> **見出しから件数を外した（2026-08-16）。** 行の増減のたびに見出しの数詞を直す必要があり、実際に順位 334 の retire で不整合になりかけた。
 
 | 順位 | 満たさない条件 | 該当箇所 |
 |---|---|---|
-| 284 | 3（重複の恐れ） | 未マージの `claude/select-next-task-a9aiam` に同タスクの実装が乗っている。タスク自体は 1・2 を満たすので、ブランチが決着したら無人可へ昇格しうる |
+| 284 | （条件ではなく lane の割り当て） | 未マージの `claude/select-next-task-a9aiam` に同タスクの実装が乗っており、人間が決着させる。**2026-08-16 の条件 3 廃止後もこの行は human lane のまま**残す — 条件を満たすかどうかではなく、担当が人間だという記録である（[ADR-072](adr/adr-072-nightly-todo-loop.md) 決定 18）。夜間ループへ渡すなら人間が `✅` を付ける |
 | 178 | 1（着手時の判断） | 「実挙動を読んで実在する invariant を**再選定する**」— 何をテストするか自体が未確定 |
-| 334 | 1（着手時の判断） | 「regex FP 精緻化 + 本文 dogfood cleanup の規模を着手前に**grep 見積り**」 |
 | 179 | 1（着手時の判断） | 「新 dev-dep 追加 or plain `#[test]` で代替を**着手時判断**」— 依存を増やす判断は無人でしない |
 | 180 | 2（実装内容が一意でない） | 「既存 private `truncate()` と escape ロジック重複、DRY 整理（共通化 or 役割分担）を**検討**」 |
 | 340 | 2（実装内容が一意でない） | 「`main.rs` の呼び出し側を I/O 無しでテスト可能にする小さな**合成関数抽出リファクタ**が要る」— 抽出の切り方が未確定 |
@@ -202,6 +229,12 @@ cargo test で検証完結するが、新規 module / lint rule / 軽微リフ
 | 239 | 採用タスク (2) Batch 1 | マージ済みのため削除 | 夜間 PR [#391](https://github.com/aloekun/claude-code-hook-test/pull/391) が 2026-08-14 にマージ。実体も確認済み — `src/cli-merge-pipeline/src/feedback/transcript.rs` に `jsonl_paths.sort_by_key(\|path\| transcript_ordering_key(path))` が存在し、`docs/todo-summary2.md` の順位 table からも削除済み |
 | 216 | 採用タスク (2) Batch 2 | 本 PR で完成させたため削除 | 夜間 PR [#394](https://github.com/aloekun/claude-code-hook-test/pull/394) は fixture 2 ファイルのみで rule 本体が無く**未完了だった**（→ [§ 未完了のままマージされた順位](#未完了のままマージされた順位)）。本 PR で rule 定義・rule test 5 件・E2E case・dogfood を実装し、完了基準（`.toml`/`.yaml`/`.yml`/`.jsonc` の `PR-` + 数字を warning 検出、`PR #NNN` は非検出）を満たしたうえで削除した |
 
+### 2026-08-16
+
+| 順位 | 節 | 判定 | 根拠 |
+|---|---|---|---|
+| 334 | 採用タスク (2) Batch 2 | **前提消滅のため retire** | 「`docs/todo*.md` 本文の順位番号表記を検出する custom lint rule」は [ADR-033](adr/adr-033-todo-numbering-simplification.md) の本文使用禁止を仕組み化するタスクだった。同 ADR § 改訂（2026-08-16）で**禁止規約そのものを緩和**したため、検出すべき違反が存在しなくなった。順位 table 行・詳細エントリ（`docs/todo14.md`）も同時に削除。**land したのではなく、やる理由が消えた**点が上 2 節と異なる |
+
 ---
 
 ## 未完了のままマージされた順位
@@ -228,21 +261,13 @@ cargo test で検証完結するが、新規 module / lint rule / 軽微リフ
 
 **残る一般的リスク**: 上記は lint rule クラスに固有の対処であり、「マージ ≠ 完了」という失敗モード自体は他のタスククラスに残る。完了基準を機械可読にして削除前に検証する仕組み（push 前セルフレビューでの決定論的な台帳自動削除 + 実装確認）を別途構築する。
 
-## 昇格検査履歴
+## 昇格検査履歴 — 廃止（2026-08-16）
 
-週次レビューの昇格候補チェック（→ [§ 定期更新（週次）](#定期更新週次) 2）で **「検査したが本台帳の採用基準を満たさない」と判定した順位**を記録する。次回以降の検査はここに載っている順位を除外し、**残り全件**を判定する。
+**本 section は廃止した。表は 1 行も記帳されないまま終わった。**
 
-**なぜ記録が要るか**: この記録が無いと、検査のたびに同じ順位（`docs/todo-summary*.md` の全 176 件規模）を先頭から評価し直すことになる。実際 2026-08-13 の実行は 164 件の候補から **約 50 件をサンプリング**して 0 件と報告しており、毎週同じ古い順位を評価して毎週不採用にする空回りが構造的に起きていた。ここに「判定済み」を積むことで、検査対象は新規登録分へ収束する。
+これは「週次レビューの LLM に `docs/todo-summary*.md` の全順位（251 件規模）を毎週判定させ、不適格と判定した順位を積んで検査対象を収束させる」ための収束機構だった。**2 週連続で機能しなかった** — 2026-08-13 は 164 件中約 50 件のサンプリングで「候補 0 件」、2026-08-15 は 251 件中 13 件しか判定せず同じく「候補 0 件」と報告した（instruction は完全に届いていた。強化を 2 回試みて 2 回とも失敗している）。
 
-**書き手は `/weekly-review` skill**（ユーザー承認後）。facet は read-only なので自分では書けない（ADR-022）。**無人可マークと同様、行の削除や採否そのものは人間の判断**である。
-
-**「対象外の理由」の書式**: 採用は docs-only / cargo-test の **2 経路 OR** なので、対象外の判定には**両経路それぞれ**について、落ちた基準番号または当該経路が適用不能である理由を必ず含める（例: `docs-only 基準 1 不適合 (Rust 実装で docs 編集に閉じない)・cargo-test 基準 2 不適合 (Windows hook 発火が成功条件)`。「cargo-test 基準 N」= [§ 採用タスク (2) の判定基準](#採用タスク-2-cargo-test-検証タスククロスプラットフォーム対応後2026-07-23) N、「docs-only 基準 N」= [§ 採用タスク の判定基準](#採用タスク) N）。片方の経路だけの理由では、もう一方の経路で昇格できる順位を恒久除外してしまう。下記「除外の解除」の再評価は、この基準番号で該当行だけを絞って行うため、番号の無い理由は再評価対象の特定を全行の再読に戻してしまう。両経路分の基準番号（または非適用理由）を特定できないまま記帳してはならない（その順位は未判定として扱い、記帳しない）。
-
-**除外の解除（再評価）**: 台帳の採用基準そのものが変わったときは、本表の該当行を削除して再評価対象へ戻す。基準変更は実際に起きている — 2026-07-23 のクロスプラットフォーム対応で、それまで対象外だった cargo-test 検証タスク群が一斉に適格化した（→ [§ 採用タスク (2)](#採用タスク-2-cargo-test-検証タスククロスプラットフォーム対応後2026-07-23)）。**「一度対象外にしたら永久に見ない」ではない**点が watermark 方式との違いで、基準を触った回に本表を棚卸しすること。
-
-| 検査日 | 順位 | 対象外の理由 |
-|---|---|---|
-| — | — | （初回の検査時に記入する。初回は台帳既載を除く全順位が対象） |
+**廃止の理由は「動かなかったから」ではなく、lane モデルで不要になったから**である（[ADR-072](adr/adr-072-nightly-todo-loop.md) 決定 18）。昇格 = 人間の割り当て判断であり、週次レビューが出すべきものは「判定済みの証跡」ではなく**判断の材料**（台帳未掲載の順位一覧）だけになった。材料は決定論的に計算できるので、収束機構も記帳義務も要らない。
 
 ## ライフサイクル
 
@@ -260,15 +285,11 @@ WP-18 の夜間 todo 消化ループがここを**タスク選択元**として
 
 棚卸しで見るもの:
 
-1. **land 済み行の削除** — `docs/todo-summary.md` / `todo-summary2.md` の順位 table から消えた行を削除し、根拠を [§棚卸し履歴](#棚卸し履歴) に記帳する。対象は**現行のタスク表のみ**（Batch 1 / Batch 2 と、非空なら [§採用タスク](#採用タスク) の表）で、[§棚卸し履歴](#棚卸し履歴) と [§無人可としなかった 7 件の理由](#無人可としなかった-7-件の理由) は対象外 — どちらも順位列を持つが、削除済み順位を意図的に残す記録だから
-2. **新規候補の昇格** — todo-summary 側に増えたタスクのうち、[§採用タスク (2) の判定基準](#採用タスク-2-cargo-test-検証タスククロスプラットフォーム対応後2026-07-23)**または** [§採用タスク の判定基準](#採用タスク)（docs-only）のいずれかを満たすものを、対応する表へ追加する。docs-only 枠は現在 0 件だが再追加を許しているため、両方の経路を見ないと候補を取りこぼす。
-
-   **検査対象の作り方（サンプリング禁止）**: `docs/todo-summary.md` + `docs/todo-summary2.md` の全順位から、**(a) 本台帳の現行タスク表に既載の順位** と **(b) [§ 昇格検査履歴](#昇格検査履歴) に載っている順位** を除外し、**残り全件**を判定する。件数が多いことを理由に一部だけ見て「候補なし」と結論してはならない。
-
-   **記帳の対象は「今回不適格と判定した順位すべて」であり、その週に候補が見つかったかどうかとは無関係。** 候補が 1 件以上あった週でも、同時に不適格と判定した順位は 1 行ずつ検査日・理由つきで [§ 昇格検査履歴](#昇格検査履歴) へ記帳する。ここを「候補 0 件の週だけ記帳する」と運用すると、候補が出た週の不適格分が除外されないまま残り、**次回また同じ順位を検査する**ことになる（本節が解こうとしている空回りそのもの）。ただし**判定できなかった順位は記帳しない** — 未判定を「検査済み」として積むと取りこぼしが恒久化する。
+1. **land 済み行の削除** — `docs/todo-summary.md` / `todo-summary2.md` の順位 table から消えた行を削除し、根拠を [§棚卸し履歴](#棚卸し履歴) に記帳する。対象は**現行のタスク表のみ**（Batch 1 / Batch 2 と、非空なら [§採用タスク](#採用タスク) の表）で、[§棚卸し履歴](#棚卸し履歴) と [§無人可としなかった理由](#無人可としなかった理由) は対象外 — どちらも順位列を持つが、削除済み順位を意図的に残す記録だから
+2. **昇格候補の材料提示** — `docs/todo-summary.md` + `docs/todo-summary2.md` の全順位から本台帳の現行タスク表に既載の順位を引いた**差集合（台帳未掲載の順位一覧）**を提示する。**判定はしない** — どれを台帳へ載せるか、載せた行の lane を `✅` にするか `—` にするかは、いずれも人間の割り当て判断である（[§ 無人可列は担当割り当て（lane）である](#無人可列は担当割り当てlaneである2026-08-16adr-072-決定-18)）。
 
-   **候補が 1 件でもある場合は必ず明示する。** 「候補なし」と報告してよいのは、上記の全件判定を実際に行ったときだけである
-3. **無人可マークの見直し** — [§自律実行可否の 2 段階分類](#自律実行可否の-2-段階分類)の 3 条件を再確認する。特に条件 3（重複の恐れ）は台帳の外にある未マージブランチ・進行中 PR を見ないと判定できないため、この棚卸しでしか確認できない
+   **差集合の計算は決定論層が行う**（LLM に全件判定させる旧方式は 2 週連続で機能せず廃止した → [§ 昇格検査履歴 — 廃止（2026-08-16）](#昇格検査履歴--廃止2026-08-16)）。検査済み順位の記帳も、収束のための除外リストも持たない — 毎回全順位から差集合を取り直すだけで、状態を持たずに同じ結果が出る。
+3. **lane の見直し** — `✅` の行が今も夜間ループの持ち物でよいかを確認する。人間が着手した / 着手する予定のタスクが `✅` のままなら `—` へ移す（この操作自体は人間が行う）。
 
 1〜3 の実行と採否は**人間が決める**（ADR-022）。facet は read-only で findings を上げるだけで、本ファイルを編集しない。
 
diff --git a/docs/todo-summary.md b/docs/todo-summary.md
index 247666cd..df7a33ad 100644
--- a/docs/todo-summary.md
+++ b/docs/todo-summary.md
@@ -2,7 +2,7 @@
 
 > **本ファイルの位置付け**: `docs/todo.md` から「推奨実行順序サマリー」section を切り出した index 専用ファイル。各タスクの詳細は「ファイル」列に示された `docs/todoN.md` を参照する。`docs/todo.md` のサイズが 50KB を超え Claude Code 読み取り安定性に影響したため分離 (2026-05-09)。
 >
-> **更新方針**: table への新規行追加・既存行の削除・順位の再採番は本 index (todo-summary.md + [docs/todo-summary2.md](todo-summary2.md)) で実施する (2026-07-20 に順位 220 以降を todo-summary2.md へ物理分割、docs 50KB 超過解消。新規行は末尾 = todo-summary2.md 側に追加)。詳細エントリは現行の追加先ファイル (= **`docs/todo23.md`**、2026-08-13 に週次レビュー WR-2026-08-13-M01 採用で新設。直前の追加先 `docs/todo22.md` が約 66KB = 50KB 安定読み取り閾値超過に達したため移行) に記録する。追加先は 50KB 到達のたびに移っており、`docs/todo13.md` → `todo14.md` (2026-07-19、WR-2026-07-19-T02) → `todo20.md` → `todo21.md` (2026-08-08) → `todo22.md` (2026-08-11) → `todo23.md` (2026-08-13) と辿ってきた。**移行済みの旧ファイルは既存エントリの編集・完了削除専用**で、新規追加先ではない。なお `docs/todo10.md` は 2026-06-29 PR #224 セッションで todo13.md へ追加先が移行するまでの旧追加先 (以降 既存エントリの編集・完了削除専用)、`docs/todo11.md` は 2026-06-06 todo9.md 分割で新設された専用ファイル (順位 157, 160-173 を収容)、`docs/todo12.md` は 2026-06-12 PR #204 で todo10.md 分割により新設された専用ファイル (順位 176/178/179/180/181/182/193/194 = PR #185 〜 PR #196 era を収容) で、いずれも新規追加先ではない。
+> **更新方針**: table への新規行追加・既存行の削除は本 index (todo-summary.md + [docs/todo-summary2.md](todo-summary2.md)) で実施する (2026-07-20 に順位 220 以降を todo-summary2.md へ物理分割、docs 50KB 超過解消。新規行は末尾 = todo-summary2.md 側に追加)。**順位は追記型の ID であり、再採番はしない** — 新規行には既存の最大 + 1 を付け、欠番は埋めない。優先度は `Tier` 列が表すため、行の並び (= 登録順) を優先度順と読まないこと ([ADR-033](adr/adr-033-todo-numbering-simplification.md) § 改訂 2026-08-16)。詳細エントリは現行の追加先ファイル (= **`docs/todo24.md`**、2026-08-16 新設。直前の追加先 `docs/todo23.md` が 52690B = 50KB 安定読み取り閾値超過に達したため移行) に記録する。追加先は 50KB 到達のたびに移っており、`docs/todo13.md` → `todo14.md` (2026-07-19、WR-2026-07-19-T02) → `todo20.md` → `todo21.md` (2026-08-08) → `todo22.md` (2026-08-11) → `todo23.md` (2026-08-13) → `todo24.md` (2026-08-16) と辿ってきた。**現在の追加先は [docs/todo.md](todo.md) の preamble が持つ routing 表が正であり、本行はその写しである** — 移行時は両方を更新すること。**移行済みの旧ファイルは既存エントリの編集・完了削除専用**で、新規追加先ではない。なお `docs/todo10.md` は 2026-06-29 PR #224 セッションで todo13.md へ追加先が移行するまでの旧追加先 (以降 既存エントリの編集・完了削除専用)、`docs/todo11.md` は 2026-06-06 todo9.md 分割で新設された専用ファイル (順位 157, 160-173 を収容)、`docs/todo12.md` は 2026-06-12 PR #204 で todo10.md 分割により新設された専用ファイル (順位 176/178/179/180/181/182/193/194 = PR #185 〜 PR #196 era を収容) で、いずれも新規追加先ではない。
 
 <a id="recommended-order-summary"></a>
 
diff --git a/docs/todo-summary2.md b/docs/todo-summary2.md
index 38cc25ec..5ac8fbd9 100644
--- a/docs/todo-summary2.md
+++ b/docs/todo-summary2.md
@@ -86,7 +86,6 @@
 | 330 | 💎 Tier 3 | **「行動要求 nudge は 2 チャネル返却」+「多義的戻り値は struct 化」convention の明文化 (#299 post-merge feedback 採用)** | todo17.md | XS | なし (ADR-059 の 2 チャネルパターンと `WeeklyReviewNudge` struct 化。第2弾展開 3件で再利用見込み。dev-conventions 1節追記) |
 | 331 | 🔧 Tier 2 | **hooks-session-start に systemMessage を含む JSON 出力の exe-spawn E2E テスト追加 (#299 post-merge feedback 採用)** | todo17.md | S | なし (現状 pure function レベルのみ、実 config パース込み exe 駆動の検証なし。ADR-049 exe-spawn E2E 先例流用。UI 実描画確認は別途 dogfood) |
 | 332 | 🔧 Tier 2 | **`pnpm build:all` 前に git usr/bin (cp.exe) PATH 未設定を自動検出・追加 (#301 post-merge feedback 採用)** | todo17.md | S | なし (Windows で pnpm が cmd.exe 経由実行のため `cp` 解決失敗。memory 既記録だが再発2回目。Windows 限定 additive 分岐、他OS非影響) |
-| 334 | 🚀 Tier 1 | **docs/todo*.md 本文の順位番号表記を検出する custom lint rule (ADR-033 使用禁止の仕組み化、#303 post-merge feedback 採用)** | todo14.md | S | なし (ADR-033 が禁止規定 + 将来の展望で lint 検討済みだが未実装 約3ヶ月。検証 grep 実証済み、literal-ban rule⑥/⑪ と同型) |
 | 335 | 🔧 Tier 2 | **post-merge-feedback の transcript 分析を cli-merge-pipeline 生成 summary index に置換 (#303 post-merge feedback 採用)** | todo14.md | M | なし (session-analysis facet が約 1.5MB transcript で 25K token limit 衝突・避難措置を自己観測。既存 filter の自然な拡張、Frequency High) |
 | 336 | 🚀 Tier 1 | **post-merge-feedback の分析ソース選定を対象 PR の commit/bookmark 照合ベースに修正 — 時刻範囲のみ選定を廃止 (#311/#312 post-merge feedback 採用)** | todo14.md | M | なし (時刻範囲のみの pre-push run / transcript 選定が並行 push (#311/#312/#313) で他 PR 知見を誤帰属、#311/#312 feedback で実地確認。post-merge-feedback 分析範囲欠陥として過去 3 回 recurrence した先行 todo の同型・より深刻版。#311 feedback=✅ / #312 feedback=🤔 と判定割れだが両者実害確認済、ADR-042 で mechanizable=Yes) |
 | 337 | 🔧 Tier 2 | **並行テストで thread::spawn 結果を Vec::collect 後に判定する pattern を custom lint 強制 (#312 post-merge feedback 採用)** | todo14.md | M | なし (#312 で遅延イテレータが実行中 thread を drop し「2 Acquired」偽陽性、collect で回避した実績。thread::spawn は 8 ファイルで使用され再発余地。対象を concurrent test 近傍限定で FP 軽減。analyzer Tier1 = mechanical enforcement → memory `feedback_tier_classification` per project Tier 2 に再分類) |
@@ -105,7 +104,7 @@
 | 351 | 💎 Tier 3 | **local LLM review の network 分離制約を明記し unverifiable finding を skip 運用 (#310 post-merge feedback 採用)** | todo14.md | S | なし (local LLM が live marker を検証できず false positive を実出力、author が手動で否定。原提案の Target ADR-038 はスコープ違いで要修正) |
 | 352 | 💎 Tier 3 | **フェーズ完了時の plan doc → ADR 転記照合チェックリストを dev-conventions.md に追加 (#333 post-merge feedback T3-2 採用)** | todo14.md | S | なし (PR #333 Phase 4 で plan doc の 6 実装決定を ADR-062 へ手動 transpose した際に漏れかけ照合で補完。60+ ADR の多段階運用で plan→ADR 同期漏れ再発見込み。lint 化非現実的だが順位261/262/274 と同型の checklist 化は overhead 最小) |
 | 353 | 💎 Tier 3 | **ADR amendment 時の「§ Amendment」節追加を dev-conventions.md チェックリスト化 (#332 post-merge feedback T3-2 採用)** | todo14.md | XS | なし (PR #332/#333 で ADR-062 が ADR-053/055/061 を amend し被 amend 側追記を都度アドホック実施。CLAUDE.md 索引の Supersedes 注記と同様に Amendment 明記を convention 化) |
-| 354 | 💎 Tier 3 | **todo ファイル削除・更新時のチェックリストを dev-conventions.md に追加 (#332 post-merge feedback T3-8 採用)** | todo14.md | XS | なし (PR #332 で todo16.md 複数セクション削除時に lint:md を 3 回以上再実行。段階削除+都度 lint:md+順位番号本文混入注意の checklist 化、専用スクリプト化 (Tier2 様子見) と独立の即応策。順位334 と相補) |
+| 354 | 💎 Tier 3 | **todo ファイル削除・更新時のチェックリストを dev-conventions.md に追加 (#332 post-merge feedback T3-8 採用)** | todo14.md | XS | なし (PR #332 で todo16.md 複数セクション削除時に lint:md を 3 回以上再実行。段階削除+都度 lint:md の checklist 化、専用スクリプト化 (Tier2 様子見) と独立の即応策。2026-08-16: 順位番号の本文混入は ADR-033 § 改訂 で許容されたため checklist 対象から外す) |
 | 355 | 💎 Tier 3 | **新規スキル作成チェックリストを dev-conventions.md に追加 (#332 post-merge feedback T3-9 採用)** | todo14.md | XS | なし (PR #332 で monthly-review skill 作成時に weekly-review を都度参照する手戻り。SKILL.md/evals.json/trigger_eval.json の 3 点セット + Phase 構成 + deploy 前 sync check を checklist 化) |
 | 356 | 🔧 Tier 2 | **weekly/monthly staleness 判定の共通 fixture parametrized test を追加 (#331 post-merge feedback T2-1 採用)** | todo14.md | S | なし (monthly_review.rs の staleness 判定が weekly_review.rs と逐語重複、片方修正で挙動乖離するリスク。同一 fixture〔threshold 境界/Missing/Stale/Unreadable/未来値/main-root canonical〕で両流路を検証、inline test module に配置) |
 | 357 | 🔧 Tier 2 | **CLAUDE.md の ADR index ステータスタグと ADR 本体の整合チェックを追加 (#340 post-merge feedback T1-1 採用)** | todo14.md | M | なし (ADR-047 の index タグが `試験運用` のまま本体の `却下` と乖離した実害が残存。ADR-007 の 2 層は単一ファイル起点のため独立 doc-consistency チェックとして実装。責務はステータスタグ整合のみで採番/索引存在/番号一致は順位 272、実装は同一 module 同居可。着手時に ADR-047 タグ即修正を含む) |
@@ -177,7 +176,7 @@
 | 438 | 🚀 Tier 1 | **孤立ブランチの回収と後始末 (nightly 未マージクローズ 3 本 + 実装孤立 2 本)** | todo22.md | M | なし (2026-08-12 scan + gh 突合。⚠ nightly ブランチの先行削除は夜間ループの再選択事故を誘発するため回収 PR マージ後にのみ削除) |
 | 439 | 🔧 Tier 2 | **決定論 gate 結果の telemetry 統合 (観測不能の再発防止)** | todo22.md | M | なし (2026-08-12 起票。B1-loop NO-GO 判定が「観測手段の欠落」で立証不能に終わった再発防止。ADR-043 § Amendment 2026-08-12 参照) |
 | 440 | 🔧 Tier 2 | **weekly-review 成果物の保存問題 (dead pointer + cloud 移行後の保存先)** | todo22.md | S-M | なし (2026-08-12 起票。last-run の指す 2026-07-27.md が不在、ADR-070 移行後の保存先未確認。jj-robustness facet の bounded-lifetime 判定 = todo13.md の blocker) |
-| 441 | 🔧 Tier 2 | **cli-docs-lint に「詳細エントリ ⇄ 台帳行」の 1:1 対応検査を追加** | todo22.md | S-M | なし (2026-08-12 起票。todo14.md の孤児 4 件が 3 週間未検出だった lint 死角。本文順位番号 lint = 順位 334 と実装共有の可能性) |
+| 441 | 🔧 Tier 2 | **cli-docs-lint に「詳細エントリ ⇄ 台帳行」の 1:1 対応検査を追加** | todo22.md | S-M | なし (2026-08-12 起票。todo14.md の孤児 4 件が 3 週間未検出だった lint 死角。2026-08-16 に採番漏れ 3 件が再発しており価値は上がっている。実装共有先だった本文順位番号 lint は同日 retire) |
 | 442 | 🔧 Tier 2 | **security facet に「新規 fail-closed 検査の抜けを敵対的に探す」観点を追加** | todo22.md | S | なし (2026-08-12 起票。ADR-056 確定判定の二重 miss 分析で最も再現性の高い失敗パターン = PR #313 Critical 3 件) |
 | 443 | 💎 Tier 3 | **fix 検証縮小 × re-gate 全 group 再実行の flaky 当たり面の縮小検討** | todo22.md | S-M | なし (2026-08-12 起票。ADR-058 確定判定で唯一の changed_block が flaky 誤 block と判明。negative result の永続化も正規の出口) |
 | 444 | 🚀 Tier 1 | **orphan reaper が success report 検出時に meta.json を running のまま残す (feedback ループ恒久停止)** | todo22.md | S | なし (2026-08-13 起票。PR #396 マージで実発生。順位 398 の guard 変更で stale meta が初めてブロック要因化) |
@@ -185,9 +184,8 @@
 | 446 | 🚀 Tier 1 | **post-merge-feedback の transcript 抽出が並列 jj workspace のセッションを取りこぼす** | todo22.md | S | なし (2026-08-13 起票。PR #395 feedback 採用。ADR-030 の分析入力が無言欠落、まず切り分け) |
 | 447 | 🚀 Tier 1 | **台帳の `✅無人可` と判断留保キーワードの矛盾を決定論層で検出 (PR #400 T1-2)** | todo23.md | S | なし (2026-08-14 採用。#400 の正準タグ規約は instruction 層のみで機械強制が無い。実装先は custom lint rule か ledger.rs の fail-closed 検査かを着手時に決める) |
 | 448 | 🔧 Tier 2 | **判断留保キーワード検査の回帰テスト (canonical / tagged / untagged の 3 分類) (PR #400 T2-1)** | todo23.md | S | 447 (検証対象が 447 の成果物。走査の実体が現状 Rust に無いため単独着手は不可) |
-| 449 | 🔧 Tier 2 | **昇格不適格判定の「両経路記載」を決定論化するかを判断 (PR #400 T2-2)** | todo23.md | S-M | なし (2026-08-14 採用。判定は facet LLM + 人間で Rust 実装が無く、決定論化しうるのは記帳形式のみ。次回 weekly-review の初回記帳実績を見てから採否。見送りも正規の出口) |
 | 450 | 🔧 Tier 2 | **push-runner の bookmark 不在を早期検出し fallback のノイズを除去 (PR #400 T2-3)** | todo23.md | S | なし (2026-08-14 実測。削除済み bookmark への fallback がパースエラーを出してから中断し、対処法が読み取りにくい) |
-| 451 | 💎 Tier 3 | **OR 条件の不成立を主張するときは全経路を明示する convention (PR #400 T3-1)** | todo23.md | XS | なし (2026-08-14 採用。#400 の CodeRabbit 指摘 3 件すべてが同一欠陥。449 の自動検出が様子見の間の人手ガイド) |
+| 451 | 💎 Tier 3 | **OR 条件の不成立を主張するときは全経路を明示する convention (PR #400 T3-1)** | todo23.md | XS | なし (2026-08-14 採用。#400 の CodeRabbit 指摘 3 件すべてが同一欠陥。対だった順位 449 は検査対象の台帳 § 昇格検査履歴 廃止により 2026-08-16 削除、本 convention は単独で成立) |
 | 452 | 💎 Tier 3 | **本リポ instruction とスキルリポ SKILL.md の同時反映チェックリスト (PR #400 T3-2)** | todo23.md | XS | なし (2026-08-14 採用。ADR-051 の具体化。スキルリポ側に約 110 行のコミット漏れが滞留していた検出も含める) |
 | 453 | 🔧 Tier 2 | **post-merge-feedback 分析 agent の書き込み先制約 (read-only facet の一時ファイル生成)** | todo23.md | S | なし (2026-08-14 起票。analyze_transcript.py の実観測。weekly の workspace-hygiene-scan が backstop、本タスクは上流修正で緊急度低) |
 | 454 | 🚀 Tier 1 | **自律実行ガードレールの 3 点同期を機械検証する (#400-#406 feedback 統合)** | todo23.md | S | なし (2026-08-15 採用。#403/#405 で 3 箇所を手で揃えた。片方漏れで保護が静かに緩み、#403 では実際に抽出で実体が保護外へ出かけた) |
@@ -195,9 +193,12 @@
 | 456 | 🚀 Tier 1 | **workflow の guard なし `git commit` を検知する (#400-#406 feedback 統合)** | todo23.md | S | なし (2026-08-15 採用。#406 で Critical を 2 度。レビューが無ければ夜間ループが停止していた) |
 | 457 | 🔧 Tier 2 | **lint rule の宣言拡張子が test_coverage で網羅されているか検査 (#400-#406 feedback 統合)** | todo23.md | S | なし (2026-08-15 採用。#402 の孤児 fixture 検査と対になる、もう 1 つの非対称。例外 allowlist の要否を着手時に決める) |
 | 458 | 🔧 Tier 2 | **`cli-ledger-cleanup` の統合テスト suite (提案 10 件を統合)** | todo23.md | M | なし (2026-08-15 採用。手動実測した安全側 3 ケースの自動化が起点。削除は取り返しがつかないため安全側こそ回り続ける必要がある) |
-| 459 | 🔧 Tier 2 | **weekly-review 周辺の決定論層テスト (提案 4 件を統合)** | todo23.md | S-M | なし (2026-08-15 採用。scan 失敗テストは検証対象が未確定 = shell のままか exe 化か。順位 448/449 と同じ構図) |
+| 459 | 🔧 Tier 2 | **weekly-review 周辺の決定論層テスト (提案 4 件を統合)** | todo23.md | S-M | なし (2026-08-15 採用。scan 失敗テストは検証対象が未確定 = shell のままか exe 化か。順位 448 と同じ構図) |
 | 460 | 💎 Tier 3 | **外部入力の信頼境界と fail-closed の徒定形を ADR 化 (提案 3 件を統合)** | todo23.md | S | なし (2026-08-15 採用。本チェーンの Critical 2 件の根本にある原則。ADR-043 の具体化として位置づける) |
 | 461 | 💎 Tier 3 | **開発 convention の一括追記 — 本チェーンの手順レベル教訓 (提案 12 件を統合)** | todo23.md | S | 460 (設計原則は ADR 側へ寄せるため先に確定させる。finding_id 埋込の方針が未決) |
+| 462 | 🚀 Tier 1 | **weekly-review facet の出力言語を output contract に明記する** | todo23.md | XS | なし (2026-08-16 採番。2026-08-15 の run で 1 facet がハングル出力・日本語ゼロ。`.takt/config.yaml` 不在で en builtin にフォールバックしており、instruction にも contract にも言語指定が無い。lane モデル work-plan PR-2 で実施) |
+| 463 | 🚀 Tier 1 | **昇格候補集合の構築を決定論層へ移す (台帳未掲載順位一覧の決定論出力)** | todo23.md | S | なし (2026-08-16 採番。LLM 全件判定は 2 週連続で失敗、lane モデルで rescope し差集合出力のみ残った。work-plan PR-3 の summary パーサを流用するため PR-3 の後が楽。lane モデル work-plan PR-5 で実施) |
+| 464 | 💎 Tier 3 | **`review-todo-whole` facet の台帳読み取り精度を決定論層で担保するか判定する** | todo24.md | S | 順位 463 (facet の報告範囲が lane モデルで縮小したため、463 land 後の実走レポートを見て要否を再判定する。不要なら理由を付して削除) |
 
 **戦略**: Tier 1 を 2〜3 セッションで片付け → Tier 2 で計測基盤 (gate telemetry / weekly-review 保存) + rate-limit + convergence cost 削減を進める → Tier 3 でドキュメント整備。Tier 4-5 は cleanup / 外部展開で daily efficiency への直接効果は小さい。(2026-08-12 更新: 旧記述の ADR-032 は ADR-057 置換で欠番)
 
diff --git a/docs/todo.md b/docs/todo.md
index 17aeb559..024b65a3 100644
--- a/docs/todo.md
+++ b/docs/todo.md
@@ -2,7 +2,7 @@
 
 > **運用ルール**: 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイル + [docs/todo3.md](todo3.md) 〜 [docs/todo23.md](todo23.md) + [docs/todo-summary.md](todo-summary.md) + [docs/todo-summary2.md](todo-summary2.md) の使い分け** (todo2.md は 2026-08-12 退役) (PR #83 T3-2 で恒久化、2026-04-28 強化、PR #88 で todo3.md 追加、PR #96 セッションで todo4.md 追加、PR #101 セッションで todo5.md 追加、PR #123 セッションで todo6.md 追加、2026-05-09 に todo-summary.md 切り出し + todo5.md 分割で todo7.md 追加、PR #143 = 2026-05-11 で todo8.md 追加、PR #172 仕組み化方針切替 = 2026-05-25 で todo9.md 追加、PR #185 land 後 2026-05-29 で todo10.md 追加、2026-06-06 todo9.md 分割で todo11.md 追加、2026-06-12 PR #204 で todo10.md 分割により todo12.md 追加、2026-06-29 PR #224 セッションで todo13.md 追加、2026-07-19 週次レビュー WR-2026-07-19-T02 採用で todo14.md 追加、2026-07-20 docs 50KB 超過解消で todo13.md を todo15/16/17・todo10.md を todo18/19 へ物理分割、2026-08-04 todo14.md の 50KB 超過で todo20.md 追加、2026-08-08 todo20.md の 50KB 超過で todo21.md 追加、2026-08-11 todo21.md の 50KB 超過で todo22.md 追加、2026-08-13 todo22.md の 50KB 超過で todo23.md 追加):
+> **本ファイル + [docs/todo3.md](todo3.md) 〜 [docs/todo24.md](todo24.md) + [docs/todo-summary.md](todo-summary.md) + [docs/todo-summary2.md](todo-summary2.md) の使い分け** (todo2.md は 2026-08-12 退役) (PR #83 T3-2 で恒久化、2026-04-28 強化、PR #88 で todo3.md 追加、PR #96 セッションで todo4.md 追加、PR #101 セッションで todo5.md 追加、PR #123 セッションで todo6.md 追加、2026-05-09 に todo-summary.md 切り出し + todo5.md 分割で todo7.md 追加、PR #143 = 2026-05-11 で todo8.md 追加、PR #172 仕組み化方針切替 = 2026-05-25 で todo9.md 追加、PR #185 land 後 2026-05-29 で todo10.md 追加、2026-06-06 todo9.md 分割で todo11.md 追加、2026-06-12 PR #204 で todo10.md 分割により todo12.md 追加、2026-06-29 PR #224 セッションで todo13.md 追加、2026-07-19 週次レビュー WR-2026-07-19-T02 採用で todo14.md 追加、2026-07-20 docs 50KB 超過解消で todo13.md を todo15/16/17・todo10.md を todo18/19 へ物理分割、2026-08-04 todo14.md の 50KB 超過で todo20.md 追加、2026-08-08 todo20.md の 50KB 超過で todo21.md 追加、2026-08-11 todo21.md の 50KB 超過で todo22.md 追加、2026-08-13 todo22.md の 50KB 超過で todo23.md 追加、2026-08-16 todo23.md の 50KB 超過で todo24.md 追加):
 >
 > - **docs/todo-summary.md**: 推奨実行順序サマリー table 専用 (旧 todo.md から切り出し)、順位 6-219 を収容。既存行編集・順位再採番はここで行う。
 > - **docs/todo-summary2.md**: todo-summary.md の table を 2026-07-20 に docs 50KB 超過解消で分割した後半 (順位 220 以降を収容)。新規行追加は末尾 = 本ファイルで行う。cli-docs-lint の priority-inversion / preamble は両 summary を統合検査。
@@ -28,9 +28,10 @@
 > - **docs/todo20.md**: 既存タスクの編集・完了削除専用。**新規タスクは追加しない** (2026-08-04 todo14.md の 50KB 超過で新設・順位 365-388 を収容、2026-08-08 に本ファイルも 50KB 超過で新規追加先は todo21.md へ移行)
 > - **docs/todo21.md**: 既存タスクの編集・完了削除専用。**新規タスクは追加しない** (約57KB に到達したため、2026-08-11 以降の新規エントリは todo22.md へ。2026-08-08 todo20.md の 50KB 超過で新設、順位 385 以降を収容)
 > - **docs/todo22.md**: 既存タスクの編集・完了削除専用。**新規タスクは追加しない** (約 66KB に到達したため、2026-08-13 以降の新規エントリは todo23.md へ。2026-08-11 todo21.md の 50KB 超過で新設)
-> - **docs/todo23.md**: 新規タスクの追加先。50KB に到達するまでは本ファイルへ追加 (2026-08-13 todo22.md の 50KB 超過で新設、週次レビュー WR-2026-08-13-M01 採用)
-> - 例外: 既存 todo.md / todo3.md 〜 todo23.md タスクと **同一ファイル / 同一コンポーネント** を編集する密結合タスクは該当ファイルに追加可 (例: `~/.claude/rules/common/git-workflow.md` 配下のグローバルルール群)
-> - **新セッションでは全 todo ファイルを確認すること** (todo.md / todo3-23.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)
+> - **docs/todo23.md**: 既存タスクの編集・完了削除専用。**新規タスクは追加しない** (52690B に到達したため、2026-08-16 以降の新規エントリは todo24.md へ。2026-08-13 todo22.md の 50KB 超過で新設、週次レビュー WR-2026-08-13-M01 採用)
+> - **docs/todo24.md**: 新規タスクの追加先。50KB に到達するまでは本ファイルへ追加 (2026-08-16 todo23.md の 50KB 超過で新設)
+> - 例外: 既存 todo.md / todo3.md 〜 todo24.md タスクと **同一ファイル / 同一コンポーネント** を編集する密結合タスクは該当ファイルに追加可 (例: `~/.claude/rules/common/git-workflow.md` 配下のグローバルルール群)
+> - **新セッションでは全 todo ファイルを確認すること** (todo.md / todo3-24.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)
 
 ---
 
@@ -40,59 +41,179 @@
 
 ## 現在進行中
 
-### 週次レビュー採用 (2026-08-13)
+### 週次レビュー採用 (2026-08-15)
 
-> 2026-08-13 の週次レビュー (whole-tree, ADR-031) で採用した findings。詳細レポートは `.claude/weekly-reviews/2026-08-13.md`。J01 (fetch_head mtime) は既存 entry (WR-2026-07-19-J01) と重複のためスキップした。
+> 2026-08-15 の週次レビュー (whole-tree, ADR-031) で採用した findings。詳細レポートは `.claude/weekly-reviews/2026-08-15.md`。検出 14 件のうち 8 件を採用、6 件 (C01/C02/C04/C05/A05/J03) は却下した。
 
-#### CLAUDE.md の ADR-030 supersedes 注記を撤回済み内容に合わせて削除 (週次レビュー WR-2026-08-13-A01 採用)
+#### file-length 800 行閾値の single source of truth 化 (週次レビュー WR-2026-08-15-A01 採用)
 
-> **動機**: `CLAUDE.md:34` が ADR-030 を「Supersedes ADR-014 full, ADR-029 partial」と宣言しているが、ADR-030 自身が 2026-08-12 にこの主張を撤回済み。ADR-014/029 は設計上 ADR-030 と並んで試験運用のまま。
+> **動機**: 800 行閾値が `.claude/hooks-config.toml` `[file_length_gate]`、`src/hooks-post-tool-comment-lint-rust/src/modified_files_check.rs` (`MAX_FILE_LINES=800`)、`src/cli-push-runner/src/stages/pr_size_check.rs` (別建ての 800/1500 行 PR 範囲チェック)、`docs/dev-conventions.md` の 4 箇所に独立定義されている。さらに 50KB の `file_size_check` と 800 行の `file_length_gate` という別物の閾値が、役割の違いを文書化しないまま混在している。
 >
-> **本タスクの位置づけ**: 週次レビュー WR-2026-08-13-A01 で採用 (severity=critical, facet=architecture, category=docs-source-drift)
+> **本タスクの位置づけ**: 週次レビュー WR-2026-08-15-A01 で採用 (severity=high, facet=architecture, category=docs-source-drift)
 >
-> **参照**: `.claude/weekly-reviews/2026-08-13.md`、`CLAUDE.md:34`
+> **参照**: `.claude/weekly-reviews/2026-08-15.md`、`.claude/hooks-config.toml` (`[file_length_gate]`)
 
-##### 背景: ADR-030 の撤回注記と CLAUDE.md 索引の乖離。1 行の docs 修正で解消する
+##### 背景: `docs/dev-conventions.md` 自身が「同一事実が複数箇所に分散する場合の変更手順」を anti-pattern として明記しており、本件はその実例に該当する
 
-##### 設計決定: `CLAUDE.md:34` の「Supersedes ADR-014 full, ADR-029 partial」注記を削除し `*(試験運用 / ...)*` のみ残す
+##### 設計決定: 800 行定数を共有 `lib-*` crate へ集約し、`modified_files_check.rs` と `pr_size_check.rs` の双方から参照する
 
-- [ ] `CLAUDE.md:34` の該当注記を削除
+- [ ] 800 行定数を共有 crate へ抽出し 2 箇所から参照する
+- [ ] `file_size_check` (edit 時 50KB) と `file_length_gate` (push 時 800 行) が意図的に別フェーズなのか redundant なのかを ADR-039 に明記する
+- [ ] `.takt/facets/instructions/file-length-watchlist.md` から authoritative source へ逆参照を張る
 
-##### 完了基準: `CLAUDE.md:34` の ADR-030 行が supersedes 主張を含まず、ADR-030 の現状 (撤回済み) と整合する
+##### 完了基準: 800 行という数値がコード上 1 箇所にのみ存在し、他の参照点がすべてそこを指す。2 種の閾値の役割差が ADR-039 に記述されている
+
+#### weekly-review reminder 閾値の共有定数化と値の test 固定 (週次レビュー WR-2026-08-15-A02 採用)
+
+> **動機**: `reminder_threshold_days` が `src/hooks-session-start/src/weekly_review.rs` の Rust default、`.claude/hooks-config.toml:61`、ADR-070 の決定本文、ADR-059 の 4 箇所以上に同期機構なしで分散している。`docs/dev-conventions.md:140` は 2026-08-13 に code default (30) と config (7) が実際に乖離し手動で調整した incident を記録済み。
+>
+> **本タスクの位置づけ**: 週次レビュー WR-2026-08-15-A02 で採用 (severity=high, facet=architecture, category=docs-source-drift)
+>
+> **参照**: `.claude/weekly-reviews/2026-08-15.md`、`.claude/hooks-config.toml:61`、`docs/dev-conventions.md:140` (2026-08-13 の乖離 incident)
+
+##### 背景: 実際に乖離した実績のある分散定義。WR-2026-08-15-A01 と同じ SSOT 欠如の系統だが、こちらは incident が既に起きている点で優先度が高い
+
+##### 設計決定: `WEEKLY_REVIEW_REMINDER_THRESHOLD_DAYS` を `src/hooks-session-start/src/lib.rs` の共有定数として抽出し、config の default deserialization から参照する
+
+- [ ] `WEEKLY_REVIEW_REMINDER_THRESHOLD_DAYS` を `src/hooks-session-start/src/lib.rs` に定義
+- [ ] config の default 値解決を当該定数経由に変更
+- [ ] `.claude/hooks-config.toml` に定数の所在を指す TOML コメントを追加
+- [ ] 定数が文書化された値 (7) と一致することを assert する test を追加
+
+##### 完了基準: `cargo test` が定数値 = 7 を固定しており、code default と config の乖離が test で検出される
+
+#### lint rule ⑥ の拡張子リスト/テスト同期義務を ADR-007 へ昇格 (週次レビュー WR-2026-08-15-A03 採用)
+
+> **動機**: lint rule ⑥ (`no-ephemeral-todo-reference`) の拡張子リストとテスト同期の義務が `.claude/custom-lint-rules.toml:257-265` の TOML コメントにしか書かれておらず、ADR-007・`docs/dev-conventions.md`・テストモジュール自身のいずれにも無い。新しい拡張子を追加した開発者が `rule_test_coverage_check` を回さずローカル `cargo test` を通し、必要なテストなしでマージし得る — ADR-007 § Lint rule 最小テストチェックリストが警告している当の anti-pattern。
+>
+> **本タスクの位置づけ**: 週次レビュー WR-2026-08-15-A03 で採用 (severity=medium, facet=architecture, category=harness-duplication)
+>
+> **参照**: `.claude/weekly-reviews/2026-08-15.md`、`.claude/custom-lint-rules.toml:274` (`.claude/custom-lint-rules.toml:257-265`)
+
+##### 背景: 列挙リストとテスト義務がセットで動く pattern は他ルールにも再利用可能だが、現状は 1 ルールの TOML コメントに閉じている
+
+##### 設計決定: ADR-007 に「列挙 + テスト義務」pattern を再利用可能な形で追補し、コード側からも逆参照を張る
+
+- [ ] ADR-007 § Case study に本 pattern を追補する
+- [ ] `src/hooks-post-tool-linter/src/main.rs` の該当テストモジュールに TOML 行を指す doc comment を追加
+- [ ] (長期・ADR-042 スコープ) `rule_test_coverage_check` が拡張子リストを TOML から直接抽出する案を検討
+
+##### 完了基準: 拡張子を追加した開発者が ADR-007 かコード上の doc comment のどちらからでもテスト義務に到達できる
+
+#### ADR-031 の reminder 閾値「既定 30 日」記述を 7 日へ訂正 (週次レビュー WR-2026-08-15-A04 採用)
+
+> **動機**: ADR-031 の 2026-08-04 更新節が SessionStart reminder を「監査リマインダー (既定 30 日)」と記述しているが、`.claude/hooks-config.toml:61` は `reminder_threshold_days=7` で、ADR-070 が 7 日を恒久値として確定している (30 日案は検討のうえ却下)。ADR-031 のテキストが実装値に対して stale。
+>
+> **本タスクの位置づけ**: 週次レビュー WR-2026-08-15-A04 で採用 (severity=medium, facet=architecture, category=adr-alignment)
+>
+> **参照**: `.claude/weekly-reviews/2026-08-15.md`、`docs/adr/adr-031-weekly-review-pipeline.md:7`
+
+##### 背景: WR-2026-08-15-A02 の分散定義のうち「文書側の値がずれている」分。A02 の定数化とは独立にテキスト訂正だけで解消する
+
+##### 設計決定: ADR-031 の 2026-08-04 更新節を 7 日恒久 (ADR-070 準拠) に訂正し、30 日が却下された理由を短く注記する
+
+- [ ] ADR-031 の該当記述を 7 日へ訂正
+- [ ] 30 日案が ADR-070 で却下された経緯を 1〜2 行で注記
+
+##### 完了基準: ADR-031 の記述が `.claude/hooks-config.toml` の実装値および ADR-070 の決定と一致する
+
+#### lib-ledger の repo_root() をコンパイル時パスから実行時探索へ (週次レビュー WR-2026-08-15-J01 採用)
+
+> **動機**: `src/lib-ledger/src/deployed_ledger.rs:30-34` の `repo_root()` が `env!("CARGO_MANIFEST_DIR")` に `"../.."` を join したコンパイル時絶対パスで解決している。workspace を移動/改名した場合や、workspace コピー間で `target/` を共有した場合 (ADR-045 のシナリオ)、コンパイル時に焼き込まれたパスが解決できず `read_ledger()` が「台帳を読めません」で panic する。
+>
+> **本タスクの位置づけ**: 週次レビュー WR-2026-08-15-J01 で採用 (severity=medium, facet=jj-robustness, category=jj-manifest-dir)
+>
+> **参照**: `.claude/weekly-reviews/2026-08-15.md`、`src/lib-ledger/src/deployed_ledger.rs:30-34`
+
+##### 背景: `CARGO_MANIFEST_DIR` のコンパイル時読みは ADR-045 が明示する脆弱性リストの 1 つ。現状は panic = fail-closed なので silent 破壊ではないが、脆弱性そのものは残る
+
+##### 設計決定: `std::env::current_dir()` から `.git` / `.claude` marker を上方探索し、fallback として `std::env::var()` で実行時に `CARGO_MANIFEST_DIR` を読む
+
+- [ ] `repo_root()` を marker 上方探索ベースに置換
+- [ ] fallback を `env!()` から `std::env::var()` へ変更
+- [ ] workspace 移動を模したテストで解決が壊れないことを固定
+
+##### 完了基準: workspace を移動/改名しても `read_ledger()` が panic せず台帳を解決できる
 
-#### 台帳の ✅無人可 5 行を condition 3 違反により — へ降格 (週次レビュー WR-2026-08-13-T02 採用)
+#### custom_rules/coverage.rs の CARGO_MANIFEST_DIR 実行時解決 (週次レビュー WR-2026-08-15-J02 採用)
 
-> **動機**: `docs/claude-code-web-tasks.md` の `✅ 無人可` 5 行 (順位 203/216/228/239/240) が § 自律実行可否の condition 3 (重複の恐れなし) に違反。各順位に未マージ PR (#373/#394/#379/#391/#378) が存在し、夜間 todo ループが重複/競合 PR を作りうる。
+> **動機**: `src/hooks-post-tool-linter/src/custom_rules/coverage.rs:22-28,68-69` の `load_deployed_custom_rules()` と `extract_existing_test_fn_names()` (いずれも `#[cfg(test)]`) が `env!("CARGO_MANIFEST_DIR")` でコンパイル時にパスを解決しており、WR-2026-08-15-J01 と同一の hazard を持つ。workspace 移動/改名や `target/` 共有で panic する。
 >
-> **本タスクの位置づけ**: 週次レビュー WR-2026-08-13-T02 で採用 (severity=high, facet=todo, category=todo-duplicate)
+> **本タスクの位置づけ**: 週次レビュー WR-2026-08-15-J02 で採用 (severity=medium, facet=jj-robustness, category=jj-manifest-dir)
 >
-> **参照**: `.claude/weekly-reviews/2026-08-13.md`、`docs/claude-code-web-tasks.md` (採用タスク Batch 1/2)
+> **参照**: `.claude/weekly-reviews/2026-08-15.md`、`src/hooks-post-tool-linter/src/custom_rules/coverage.rs:22-28,68-69`
 
-##### 背景: ADR-072 の夜間ループは無人可マークを機械的に読む。マークが古いと重複実装 PR を生む
+##### 背景: J01 と同一パターンだが別ファイル・テスト専用コードのため別 finding として追跡する。J01 の修正方針が決まれば機械的に適用できる
 
-##### 設計決定: 該当 5 行の `✅ 無人可` を `—` へ降格し、理由を § 無人可としなかった…理由 表に記録する。PR がマージ or 恒久 close + untrack されるまで
+##### 設計決定: 両関数の `env!("CARGO_MANIFEST_DIR")` を `std::env::var(...)` による実行時解決へ置換する
 
-- [ ] 順位 203/216/228/239/240 の 無人可 を `—` へ (**人間が実施** — マークは人間が付ける、ADR-022)
-- [ ] § 無人可としなかった…理由 表に根拠を追記
+- [ ] `load_deployed_custom_rules()` の解決を実行時化
+- [ ] `extract_existing_test_fn_names()` の解決を実行時化
 
-##### 完了基準: 当該 5 行が `無人可=—`、理由表に PR 番号付きで記録
+##### 完了基準: workspace 移動後も当該 2 関数を含むテストが panic せず通る
 
-#### 台帳 Batch 1 の closed-without-merge 行を棚卸し履歴へ移動し、in-flight を明示 (週次レビュー WR-2026-08-13-T01 採用)
+#### lint-screen eval E2E に閾値 assertion を入れる判断 (週次レビュー WR-2026-08-15-S01 採用)
 
-> **動機**: `docs/claude-code-web-tasks.md` Batch 1 の順位 203/228/240 は nightly PR (#373/#379/#378) が unmerged close されたのに active のまま残存。順位 239 は open PR (#391) が in-flight として反映されていない。
+> **動機**: `src/cli-finding-classifier/tests/lint_screen_evals/e2e.rs:53-84` の `run_lint_screen_against_all_fixtures` は Ollama + lint-screen の全 pipeline を全 eval fixture に対して実行するが assertion が 1 つも無く、metrics を人間解釈用に print するだけ (line 76)。LLM の判定精度を劣化させる PR が、誰かが出力を目視しない限り無言で通る。
 >
-> **本タスクの位置づけ**: 週次レビュー WR-2026-08-13-T01 で採用 (severity=medium, facet=todo, category=todo-dead-entry)
+> **本タスクの位置づけ**: 週次レビュー WR-2026-08-15-S01 で採用 (severity=medium, facet=simplicity, category=test-anti-pattern)
 >
-> **参照**: `.claude/weekly-reviews/2026-08-13.md`、`docs/claude-code-web-tasks.md` (採用タスク Batch 1)
+> **参照**: `.claude/weekly-reviews/2026-08-15.md`、`src/cli-finding-classifier/tests/lint_screen_evals/e2e.rs:53-84`
 
-##### 背景: 台帳の鮮度は「行が消えていること」でしか表現されないため、closed 行の残存が棚卸し漏れになる
+##### 背景: 現状は `#[ignore]` + `LINT_SCREEN_EVALS` env による opt-in で、ADR-038 が本テストを「検証ゲートではなく実験的計測ツール」と位置づけている。即時対応は不要という判断が finding 自身に含まれる
 
-##### 設計決定: closed-without-merge 行 (203/228/240) を Batch 1 から削除し § 棚卸し履歴 に closed 理由を記録、open-PR 行 (239) を in-flight として明示する
+##### 設計決定: ADR-038 の試験運用ステータスが解けて CI 昇格へ動く時点で `report_summary` (line 83) に閾値 assertion (例: `assert!(f1_score >= BASELINE_F1)`) を入れる
 
-- [ ] 203/228/240 を Batch 1 から削除 + § 棚卸し履歴 記帳
-- [ ] 239 の in-flight 状態を明示
+- [ ] ADR-038 の試験運用判定の出口条件に「eval E2E の assertion 化」を紐づける
+- [ ] CI 昇格時に baseline F1 を決めて `report_summary` へ assertion を追加
+
+##### 完了基準: ADR-038 の採否が確定した時点で、本テストが計測専用のままか assertion 付き検証ゲートかが明示的に決まっている
+
+#### INJECTION_SIGNALS 語彙を dogfood 観測から拡充する (週次レビュー WR-2026-08-15-C03 採用)
+
+> **動機**: `src/cli-finding-classifier/src/lib.rs:84-102` の `INJECTION_SIGNALS` (17 文字列) は意図的に非網羅で、間接命令形 (「assuming this is false positive」)、suffix-injection 変種、テンプレート置換 (「this is ${action} recommendation」) といった既知の回避パターンを捕捉しない。層 1 は補助的かつ fail-open で、層 2 (fix.md allowlist) と層 3 (scope guard, fail-closed) が主防御。
+>
+> **本タスクの位置づけ**: 週次レビュー WR-2026-08-15-C03 で採用 (severity=low, facet=security, category=prompt-injection)
+>
+> **参照**: `.claude/weekly-reviews/2026-08-15.md`、`src/cli-finding-classifier/src/lib.rs:84-102`、ADR-054 (prompt injection 信頼境界の 3 層防御)
 
-##### 完了基準: Batch 1 に unmerged-close 行が残らず、棚卸し履歴に根拠が残り、順位 239 が in-flight として明示されている
+##### 背景: 回帰ではなく ADR-054 が設計として織り込んだ運用モデル。語彙は dogfood で観測した実例から育てる前提になっている
+
+##### 設計決定: dogfood 中に観測した回避試行を記録し、対応する test fixture とセットで `INJECTION_SIGNALS` に追加していく
+
+- [ ] 観測した回避試行を記録する運用先を決める (feedback-reports / todo のいずれか)
+- [ ] 観測実例が出た時点で fixture 付きで語彙へ追加
+
+##### 完了基準: 回避試行が観測された際に、語彙追加と fixture 追加がセットで行われる経路が確立している
+
+### 週次レビュー採用 (2026-08-13)
+
+> 2026-08-13 の週次レビュー (whole-tree, ADR-031) で採用した findings。詳細レポートは `.claude/weekly-reviews/2026-08-13.md`。J01 (fetch_head mtime) は既存 entry (WR-2026-07-19-J01) と重複のためスキップした。
+
+#### CLAUDE.md の ADR-030 supersedes 注記を撤回済み内容に合わせて削除 (週次レビュー WR-2026-08-13-A01 採用)
+
+> **動機**: `CLAUDE.md:34` が ADR-030 を「Supersedes ADR-014 full, ADR-029 partial」と宣言しているが、ADR-030 自身が 2026-08-12 にこの主張を撤回済み。ADR-014/029 は設計上 ADR-030 と並んで試験運用のまま。
+>
+> **本タスクの位置づけ**: 週次レビュー WR-2026-08-13-A01 で採用 (severity=critical, facet=architecture, category=docs-source-drift)
+>
+> **参照**: `.claude/weekly-reviews/2026-08-13.md`、`CLAUDE.md:34`
+
+##### 背景: ADR-030 の撤回注記と CLAUDE.md 索引の乖離。1 行の docs 修正で解消する
+
+##### 設計決定: `CLAUDE.md:34` の「Supersedes ADR-014 full, ADR-029 partial」注記を削除し `*(試験運用 / ...)*` のみ残す
+
+- [ ] `CLAUDE.md:34` の該当注記を削除
+
+##### 完了基準: `CLAUDE.md:34` の ADR-030 行が supersedes 主張を含まず、ADR-030 の現状 (撤回済み) と整合する
+
+#### 撤回: WR-2026-08-13-T01 / T02 (台帳 finding 2 件) — 2026-08-16
+
+> **採用済みだったが実行せずに撤回した 2 件**。採用の記録だけ消えると「なぜ実行されなかったのか」が追えなくなるため、撤回の事実をここに残す (エントリ本体は削除済み)。
+>
+> - **WR-2026-08-13-T02**「台帳の ✅無人可 5 行を condition 3 違反により — へ降格」— 前提が二重に消滅した。対象ブランチは 2026-08-15 に削除済みで順位 216/239 は完了済み、さらに根拠だった **condition 3 自体を 2026-08-16 に廃止**した ([ADR-072](adr/adr-072-nightly-todo-loop.md) 決定 18)
+> - **WR-2026-08-13-T01**「台帳 Batch 1 の closed-without-merge 行を棚卸し履歴へ移動し、in-flight を明示」— 台帳の明文規定「削除するのはマージした順位だけ」と矛盾する。実行すると**未完了タスク 3 件 (順位 203/228/240) が台帳から消える**
+>
+> **撤回の一般的な含意**: どちらも condition 3 と ADR-072 決定 3 が同じブランチを逆に解釈していたことから生まれた finding である。レビューが正しく規則を適用しても、規則同士が矛盾していれば誤った採用に至る — 採用の是非は finding 単体ではなく、根拠にした規則の整合性まで見ないと判定できない。
 
 #### docs/todo23.md を新設し、新規追加先ポインタを更新する — todo22.md 50KB 超過 (週次レビュー WR-2026-08-13-M01 採用)
 
diff --git a/docs/todo10.md b/docs/todo10.md
index e04a6dcf..f090b76f 100644
--- a/docs/todo10.md
+++ b/docs/todo10.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo9.md がファイルサイズ 50KB を超え行数 1100+ 行に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して新規エントリは本ファイルに記録する (PR #185 = Bundle CR-RL land 後、2026-05-29 ユーザー判断)。**本ファイルは既存タスクの編集・完了削除専用** (新規エントリの追加先は PR #224 セッション = 2026-06-29 で [docs/todo13.md](todo13.md) へ移行し、その後 todo14.md → todo20.md → todo21.md を経て、**現在は [docs/todo23.md](todo23.md)** (2026-08-13 に todo22.md が 50KB 超過で移行)。2026-06-12 PR #204 で PR #185 〜 PR #196 era の 8 エントリを [docs/todo12.md](todo12.md) に分離して file_size_check 50KB threshold 内に収めた、todo12.md は新規追加先ではない)。todo.md / todo3.md 〜 todo9.md / todo11.md / todo12.md の既存エントリ (todo2.md は 2026-08-12 退役)は引き続き有効、相互に独立。**2026-07-20 に順位 215-224 を todo18.md/todo19.md へ物理分割し、本ファイルは順位 198-214 のみ収容 (docs 50KB 超過解消、39KB 台に縮小)。**新セッションでは24つすべてを確認すること (todo.md / todo3-23.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
+> **本ファイルの位置付け**: docs/todo9.md がファイルサイズ 50KB を超え行数 1100+ 行に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して新規エントリは本ファイルに記録する (PR #185 = Bundle CR-RL land 後、2026-05-29 ユーザー判断)。**本ファイルは既存タスクの編集・完了削除専用** (新規エントリの追加先は PR #224 セッション = 2026-06-29 で [docs/todo13.md](todo13.md) へ移行し、その後 todo14.md → todo20.md → todo21.md を経て、**現在は [docs/todo24.md](todo24.md)** (2026-08-16 に todo23.md が 50KB 超過で移行)。2026-06-12 PR #204 で PR #185 〜 PR #196 era の 8 エントリを [docs/todo12.md](todo12.md) に分離して file_size_check 50KB threshold 内に収めた、todo12.md は新規追加先ではない)。todo.md / todo3.md 〜 todo9.md / todo11.md / todo12.md の既存エントリ (todo2.md は 2026-08-12 退役)は引き続き有効、相互に独立。**2026-07-20 に順位 215-224 を todo18.md/todo19.md へ物理分割し、本ファイルは順位 198-214 のみ収容 (docs 50KB 超過解消、39KB 台に縮小)。**新セッションでは25つすべてを確認すること (todo.md / todo3-24.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo11.md b/docs/todo11.md
index 1ff33885..2883cd92 100644
--- a/docs/todo11.md
+++ b/docs/todo11.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo9.md がファイルサイズ 75KB 超 (890 行) に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して、PR-specific follow-up entries (PR #174 以降の post-merge-feedback 採用 entry) を本ファイルに分離 (2026-06-06)。todo9.md には「既存ルール仕組み化バンドル + 週次レビュー拡張」themed entries が残る。todo.md / todo3.md 〜 todo10.md の既存エントリ (todo2.md は 2026-08-12 退役)は引き続き有効、相互に独立。新セッションでは24つすべてを確認すること (todo.md / todo3-23.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
+> **本ファイルの位置付け**: docs/todo9.md がファイルサイズ 75KB 超 (890 行) に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して、PR-specific follow-up entries (PR #174 以降の post-merge-feedback 採用 entry) を本ファイルに分離 (2026-06-06)。todo9.md には「既存ルール仕組み化バンドル + 週次レビュー拡張」themed entries が残る。todo.md / todo3.md 〜 todo10.md の既存エントリ (todo2.md は 2026-08-12 退役)は引き続き有効、相互に独立。新セッションでは25つすべてを確認すること (todo.md / todo3-24.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo13.md b/docs/todo13.md
index 281e51ab..e511229d 100644
--- a/docs/todo13.md
+++ b/docs/todo13.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo10.md がファイルサイズ約 95KB (50KB 安定読み取り閾値の約 2 倍) に到達したため、新規エントリを本ファイルに記録していた (PR #224 セッション、2026-06-29 ユーザー判断)。**本ファイルも約 171KB に到達したため、新規エントリの追加先は 2026-07-19 (週次レビュー WR-2026-07-19-T02 採用) に [docs/todo14.md](todo14.md) へ移動し、その todo14.md も約 70KB に達したため 2026-08-04 以降の追加先は [docs/todo20.md](todo20.md)、さらに todo20.md も 50KB 超過で 2026-08-08 以降は [docs/todo21.md](todo21.md) である。本ファイルは既存タスクの編集・完了削除専用**。todo.md / todo2.md 〜 todo12.md / todo14.md 〜 todo21.md の既存エントリは引き続き有効、相互に独立。**2026-07-20 に順位 248-332 を todo15.md/todo16.md/todo17.md へ物理分割し、本ファイルは順位 225-247 のみ収容 (docs 50KB 超過解消、45KB 台に縮小)。**
+> **本ファイルの位置付け**: docs/todo10.md がファイルサイズ約 95KB (50KB 安定読み取り閾値の約 2 倍) に到達したため、新規エントリを本ファイルに記録していた (PR #224 セッション、2026-06-29 ユーザー判断)。**本ファイルも約 171KB に到達したため、新規エントリの追加先は 2026-07-19 (週次レビュー WR-2026-07-19-T02 採用) に [docs/todo14.md](todo14.md) へ移動した。以後も 50KB 到達のたびに移っており、現在の追加先は [docs/todo.md](todo.md) preamble の routing 表が正である (2026-08-16 時点は todo24.md)。本ファイルは既存タスクの編集・完了削除専用**。todo.md / todo3.md 〜 todo12.md / todo14.md 〜 todo24.md の既存エントリは引き続き有効、相互に独立。**2026-07-20 に順位 248-332 を todo15.md/todo16.md/todo17.md へ物理分割し、本ファイルは順位 225-247 のみ収容 (docs 50KB 超過解消、45KB 台に縮小)。**
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo14.md b/docs/todo14.md
index fe1394be..85837849 100644
--- a/docs/todo14.md
+++ b/docs/todo14.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo13.md がファイルサイズ約 171KB (50KB 安定読み取り閾値の約 3.4 倍) に到達したため、2026-07-19 週次レビュー WR-2026-07-19-T02 採用時に新設した。**本ファイル自体も約 70KB に到達したため新規エントリは追加しない** — 2026-08-04 以降の新規エントリは [docs/todo20.md](todo20.md) へ記録していたが、todo20.md も 50KB 超過で 2026-08-08 以降は todo21.md、その todo21.md も 50KB 超過で **2026-08-11 以降の追加先は [docs/todo22.md](todo22.md)** である。todo.md / todo3.md 〜 todo22.md の既存エントリは引き続き有効、相互に独立 (todo2.md は 2026-08-12 退役) (2026-07-20 に todo13.md→todo15/16/17・todo10.md→todo18/19 の物理分割で todo15-19 を新設)。
+> **本ファイルの位置付け**: docs/todo13.md がファイルサイズ約 171KB (50KB 安定読み取り閾値の約 3.4 倍) に到達したため、2026-07-19 週次レビュー WR-2026-07-19-T02 採用時に新設した。**本ファイル自体も約 70KB に到達したため新規エントリは追加しない** — 2026-08-04 以降の新規エントリは [docs/todo20.md](todo20.md) へ記録していたが、todo20.md も 50KB 超過で 2026-08-08 以降は todo21.md、その todo21.md も 50KB 超過で 2026-08-11 以降は todo22.md へ移った。**現在の追加先は [docs/todo.md](todo.md) preamble の routing 表が正である** (2026-08-16 時点は todo24.md)。todo.md / todo3.md 〜 todo22.md の既存エントリは引き続き有効、相互に独立 (todo2.md は 2026-08-12 退役) (2026-07-20 に todo13.md→todo15/16/17・todo10.md→todo18/19 の物理分割で todo15-19 を新設)。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
@@ -99,28 +99,6 @@
 ---
 
 
-### docs/todo*.md 本文の順位番号表記を検出する custom lint rule (ADR-033 使用禁止の仕組み化、#303 post-merge feedback 採用)
-
-> **動機**: [ADR-033](adr/adr-033-todo-numbering-simplification.md) (2026-04-29 試験運用) が「絶対番号は table のみに保持し、本文中の順位番号表記は使用禁止」と規定し、「将来の展望」節で pre-push hook の custom_lint_rule 追加を検討済みと明記したが、未実装のまま約 3 ヶ月経過。#303 の CodeRabbit 対応でも本文参照の drift が問題化した文脈。#303 post-merge feedback で採用。
->
-> **対処案**: `.claude/custom-lint-rules.toml` に regex rule を追加し、`docs/todo*.md` の本文 (table 行を除く) に残る順位番号の literal 表記を検出する。ADR-033 の検証用 grep が既に動作実証済みのため rule 化の Effort は S。既存の literal-ban 系 custom rule (rule⑥/⑪) と同型。
->
-> **参照**: `.claude/feedback-reports/303.md` Tier1 #2、[ADR-033](adr/adr-033-todo-numbering-simplification.md) (§ 将来の展望)、`.claude/custom-lint-rules.toml`。
->
-> **実行優先度**: 🚀 Tier 1 — Severity Medium / Frequency Medium / Effort S / Adoption Risk None (ADR-033 で既に禁止規定 + 検証 grep 実証済み)。
-
-#### 作業計画
-
-- [ ] `.claude/custom-lint-rules.toml` に `docs/todo*.md` 本文の順位番号表記を検出する regex rule を追加 (table 行を除外)
-- [ ] 既存本文の違反を洗い出し修正 (ADR-033 の grep を流用)
-- [ ] 本エントリ削除 + todo-summary2.md 行削除
-
-#### 完了基準
-
-- `docs/todo*.md` 本文に順位番号表記が混入した場合、pre-push / PostToolUse で決定論的に検出されること (ADR-033 の規定が仕組みで強制される)。
-
----
-
 ### post-merge-feedback の transcript 分析を cli-merge-pipeline 生成の summary index に置換
 
 > **動機**: post-merge-feedback の session-analysis facet が、大きな transcript (#303 マージ時は約 1.5MB / 427 行) で 25K token limit に衝突し、Grep + 手動パースの避難措置を要した (aggregate 工程の自己観測)。cli-merge-pipeline は既に transcript filter を実施済みのため、index 出力の追加は自然な拡張。#303 post-merge feedback で採用。
@@ -523,16 +501,18 @@
 
 > **動機**: PR #332 で todo16.md の複数セクション削除時に lint:md を 3 回以上再実行する非効率を観測した。todo ファイルの段階的削除と都度 lint:md 実行の手順が明文化されておらず、削除漏れ・lint 崩れ・summary 行との不整合が起きやすい。#332 post-merge feedback Tier3 #8 で採用。専用スクリプト化 (#332 Tier2 #1) は ADR-033 効果待ちで様子見だが、チェックリスト明記自体は Effort XS の無リスク即応策として独立採用可能。
 >
-> **対処案**: `docs/dev-conventions.md` に「todo ファイルの削除・更新時は (1) 詳細エントリ (todoNN.md) と summary 行 (todo-summary2.md) を対で更新、(2) 段階的に削除し都度 lint:md で整合確認、(3) 順位番号の本文混入 ([ADR-033](adr/adr-033-todo-numbering-simplification.md)) に注意」のチェックリストを追加する。
+> **対処案**: `docs/dev-conventions.md` に「todo ファイルの削除・更新時は (1) 詳細エントリ (todoNN.md) と summary 行 (**該当順位を収める `docs/todo-summary.md` または `docs/todo-summary2.md`**。順位 220 未満は前者) を対で更新、(2) 段階的に削除し都度 lint:md で整合確認、(3) 削除する順位を指す本文参照を残さない ([ADR-033](adr/adr-033-todo-numbering-simplification.md) § アンチパターン)」のチェックリストを追加する。
 >
-> **参照**: `.claude/feedback-reports/332.md` Tier3 #8、`docs/dev-conventions.md`、[ADR-033](adr/adr-033-todo-numbering-simplification.md)、todo14.md 順位334 (順位番号 lint rule と相補)。
+> **2026-08-16 更新**: 当初の対処案 (3) は「順位番号を本文に書かない」だったが、[ADR-033](adr/adr-033-todo-numbering-simplification.md) § 改訂 が本文参照の禁止を緩和したため、**削除済み順位への参照を残さない**へ置き換えた。相補関係にあった順位番号 lint rule のタスクは同日 retire している。
+>
+> **参照**: `.claude/feedback-reports/332.md` Tier3 #8、`docs/dev-conventions.md`、[ADR-033](adr/adr-033-todo-numbering-simplification.md)。
 >
 > **実行優先度**: 💎 Tier 3 — Severity Low / Frequency Medium / Effort XS / Adoption Risk None。
 
 #### 作業計画
 
-- [ ] `docs/dev-conventions.md` に todo ファイル削除・更新チェックリストを追加 (詳細/summary の対更新・段階削除+都度 lint:md・順位番号の本文混入注意)
-- [ ] 本エントリ削除 + todo-summary2.md 行削除
+- [ ] `docs/dev-conventions.md` に todo ファイル削除・更新チェックリストを追加 (詳細/summary の対更新・段階削除+都度 lint:md・削除済み順位への本文参照を残さない)
+- [ ] 本エントリ削除 + 該当順位を収める summary index (`docs/todo-summary.md` または `docs/todo-summary2.md`) の行削除
 
 #### 完了基準
 
diff --git a/docs/todo15.md b/docs/todo15.md
index c76c85c5..64cb517b 100644
--- a/docs/todo15.md
+++ b/docs/todo15.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo13.md がファイルサイズ約 171KB (50KB 安定読み取り閾値の約 3.4 倍) に達したため、順位 248〜296 のエントリを本ファイルに分離した (2026-07-20 docs 50KB 超過解消の物理分割)。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo2.md 〜 todo19.md の既存エントリは引き続き有効、相互に独立。
+> **本ファイルの位置付け**: docs/todo13.md がファイルサイズ約 171KB (50KB 安定読み取り閾値の約 3.4 倍) に達したため、順位 248〜296 のエントリを本ファイルに分離した (2026-07-20 docs 50KB 超過解消の物理分割)。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo3.md 〜 todo19.md の既存エントリは引き続き有効、相互に独立。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo16.md b/docs/todo16.md
index ae485cc3..665f2dce 100644
--- a/docs/todo16.md
+++ b/docs/todo16.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo13.md がファイルサイズ約 171KB (50KB 安定読み取り閾値の約 3.4 倍) に達したため、順位 297〜318 のエントリを本ファイルに分離した (2026-07-20 docs 50KB 超過解消の物理分割)。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo2.md 〜 todo19.md の既存エントリは引き続き有効、相互に独立。
+> **本ファイルの位置付け**: docs/todo13.md がファイルサイズ約 171KB (50KB 安定読み取り閾値の約 3.4 倍) に達したため、順位 297〜318 のエントリを本ファイルに分離した (2026-07-20 docs 50KB 超過解消の物理分割)。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo3.md 〜 todo19.md の既存エントリは引き続き有効、相互に独立。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo17.md b/docs/todo17.md
index 3ead292c..b12f196b 100644
--- a/docs/todo17.md
+++ b/docs/todo17.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo13.md がファイルサイズ約 171KB (50KB 安定読み取り閾値の約 3.4 倍) に達したため、順位 319〜332 のエントリを本ファイルに分離した (2026-07-20 docs 50KB 超過解消の物理分割)。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo2.md 〜 todo19.md の既存エントリは引き続き有効、相互に独立。
+> **本ファイルの位置付け**: docs/todo13.md がファイルサイズ約 171KB (50KB 安定読み取り閾値の約 3.4 倍) に達したため、順位 319〜332 のエントリを本ファイルに分離した (2026-07-20 docs 50KB 超過解消の物理分割)。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo3.md 〜 todo19.md の既存エントリは引き続き有効、相互に独立。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo18.md b/docs/todo18.md
index fafc84e2..d7d145e4 100644
--- a/docs/todo18.md
+++ b/docs/todo18.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo10.md がファイルサイズ約 95KB (50KB 安定読み取り閾値の約 1.9 倍) に達したため、順位 215〜219 のエントリを本ファイルに分離した (2026-07-20 docs 50KB 超過解消の物理分割)。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo2.md 〜 todo19.md の既存エントリは引き続き有効、相互に独立。
+> **本ファイルの位置付け**: docs/todo10.md がファイルサイズ約 95KB (50KB 安定読み取り閾値の約 1.9 倍) に達したため、順位 215〜219 のエントリを本ファイルに分離した (2026-07-20 docs 50KB 超過解消の物理分割)。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo3.md 〜 todo19.md の既存エントリは引き続き有効、相互に独立。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo19.md b/docs/todo19.md
index 1d082ca7..7fa40976 100644
--- a/docs/todo19.md
+++ b/docs/todo19.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo10.md がファイルサイズ約 95KB (50KB 安定読み取り閾値の約 1.9 倍) に達したため、順位 220〜224 のエントリを本ファイルに分離した (2026-07-20 docs 50KB 超過解消の物理分割)。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo2.md 〜 todo19.md の既存エントリは引き続き有効、相互に独立。
+> **本ファイルの位置付け**: docs/todo10.md がファイルサイズ約 95KB (50KB 安定読み取り閾値の約 1.9 倍) に達したため、順位 220〜224 のエントリを本ファイルに分離した (2026-07-20 docs 50KB 超過解消の物理分割)。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo3.md 〜 todo19.md の既存エントリは引き続き有効、相互に独立。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo20.md b/docs/todo20.md
index d18b293a..d4247743 100644
--- a/docs/todo20.md
+++ b/docs/todo20.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo14.md がファイルサイズ約 70KB (50KB 安定読み取り閾値の約 1.4 倍) に到達したため、新規エントリを本ファイルに記録していた (2026-08-04 WP-17 段 2 完了時の post-merge feedback 一括登録で新設)。**本ファイルも約 56KB (50KB 閾値超過) に到達したため、2026-08-08 WP-18 セッション以降の新規エントリは [docs/todo21.md](todo21.md) へ記録する。本ファイルは既存タスクの編集・完了削除専用**。todo.md / todo2.md 〜 todo19.md / todo21.md の既存エントリは引き続き有効、相互に独立。
+> **本ファイルの位置付け**: docs/todo14.md がファイルサイズ約 70KB (50KB 安定読み取り閾値の約 1.4 倍) に到達したため、新規エントリを本ファイルに記録していた (2026-08-04 WP-17 段 2 完了時の post-merge feedback 一括登録で新設)。**本ファイルも約 56KB (50KB 閾値超過) に到達したため、2026-08-08 WP-18 セッション以降の新規エントリは [docs/todo21.md](todo21.md) へ移った。以後も 50KB 到達のたびに移っており、現在の追加先は [docs/todo.md](todo.md) preamble の routing 表が正である (2026-08-16 時点は todo24.md)。本ファイルは既存タスクの編集・完了削除専用**。todo.md / todo3.md 〜 todo19.md / todo21.md 〜 todo24.md の既存エントリは引き続き有効、相互に独立。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo21.md b/docs/todo21.md
index 0c8e1461..6c5fa903 100644
--- a/docs/todo21.md
+++ b/docs/todo21.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo20.md がファイルサイズ約 56KB (50KB 安定読み取り閾値超過) に到達したため新設した (2026-08-08 WP-18 セッションの docs バッチ)。**本ファイルも約 57KB に到達したため、新規エントリの追加先は [docs/todo22.md](todo22.md) へ移った** (2026-08-11)。本ファイルの既存エントリは引き続き有効、相互に独立。
+> **本ファイルの位置付け**: docs/todo20.md がファイルサイズ約 56KB (50KB 安定読み取り閾値超過) に到達したため新設した (2026-08-08 WP-18 セッションの docs バッチ)。**本ファイルも約 57KB に到達したため、新規エントリの追加先は [docs/todo22.md](todo22.md) へ移った** (2026-08-11)。以後も 50KB 到達のたびに移っており、現在の追加先は [docs/todo.md](todo.md) preamble の routing 表が正である (2026-08-16 時点は todo24.md)。本ファイルの既存エントリは引き続き有効、相互に独立。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo22.md b/docs/todo22.md
index ba64c79b..fb84ab5f 100644
--- a/docs/todo22.md
+++ b/docs/todo22.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo21.md がファイルサイズ約 57KB (50KB 安定読み取り閾値超過) に到達したため、新規エントリは本ファイルに記録する (2026-08-11 の post-merge feedback 採否バッチで新設)。**新規エントリの追加先は本ファイル**。todo.md / todo2.md 〜 todo21.md の既存エントリは引き続き有効、相互に独立。
+> **本ファイルの位置付け**: docs/todo21.md がファイルサイズ約 57KB (50KB 安定読み取り閾値超過) に到達したため、新規エントリは本ファイルに記録する (2026-08-11 の post-merge feedback 採否バッチで新設)。**本ファイルは既存タスクの編集・完了削除専用** (2026-08-13 に todo23.md へ移行。現在の追加先は [docs/todo24.md](todo24.md))。todo.md / todo3.md 〜 todo21.md の既存エントリは引き続き有効、相互に独立。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
@@ -584,7 +584,9 @@
 
 > **動機**: todo14.md に台帳 (todo-summary*.md) の順位行を持たない孤児エントリが 4 件、約 3 週間検出されずに滞留していた (2026-08-12 の棚卸しで発見、同日採番して解消)。既存の cli-docs-lint validator は preamble (数詞照合) / cross_ref / priority_inversion の 3 種のみで、詳細エントリと台帳行の対応は検査されない。ADR-033 の「絶対番号は table のみ」規約は、対応検査が無いと片側だけの登録を許してしまう。
 >
-> **対処案**: todoN.md の `### ` 見出しタイトルと summary の「タスク」列の突合 (完全一致は求めず、summary 側がタイトル文字列を含む等の許容度設計が必要)。todo14.md 起票済みの「本文の順位番号表記を検出する custom lint rule」と実装を共有できる可能性がある。
+> **対処案**: todoN.md の `### ` 見出しタイトルと summary の「タスク」列の突合 (完全一致は求めず、summary 側がタイトル文字列を含む等の許容度設計が必要)。~~todo14.md 起票済みの「本文の順位番号表記を検出する custom lint rule」と実装を共有できる可能性がある~~ → 当該 lint rule は [ADR-033](adr/adr-033-todo-numbering-simplification.md) § 改訂 (2026-08-16) で不要になり retire したため、本タスクは単独で実装する。
+>
+> **2026-08-16 追記**: 同じ採番漏れが再発した (lane モデル PR-1 で登録した詳細エントリ 3 件に順位行が無く、手作業で 462-464 を採番して解消)。**孤児の発生源は「順位を後から付ける運用」そのもの**であり、検査を入れるまで再発し続ける。
 >
 > **実行優先度**: 🔧 Tier 2 — Severity Medium (台帳整合性) / Frequency Low〜Medium / Effort S-M。
 
diff --git a/docs/todo23.md b/docs/todo23.md
index 597ef076..2612e3bf 100644
--- a/docs/todo23.md
+++ b/docs/todo23.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo22.md がファイルサイズ 66528 B (2026-08-13 時点、50KB = 51200 B の安定読み取り閾値超過) に到達したため、新規エントリは本ファイルに記録する (2026-08-13 新設、週次レビュー WR-2026-08-13-M01 採用)。**新規エントリの追加先は本ファイル**。todo.md / todo3.md 〜 todo22.md の既存エントリは引き続き有効、相互に独立。
+> **本ファイルの位置付け**: docs/todo22.md がファイルサイズ 66528 B (2026-08-13 時点、50KB = 51200 B の安定読み取り閾値超過) に到達したため、新規エントリは本ファイルに記録する (2026-08-13 新設、週次レビュー WR-2026-08-13-M01 採用)。**本ファイルは既存タスクの編集・完了削除専用** (52690 B に到達したため、2026-08-16 以降の新規エントリは [docs/todo24.md](todo24.md) へ)。todo.md / todo3.md 〜 todo22.md の既存エントリは引き続き有効、相互に独立。
 >
 > **サイズ表記について**: todo22.md のサイズは記録時点で異なる (週次レビュー検出時 54203 B → 本ファイル新設時 66528 B → その後の追記でさらに増加)。各記載は**その時点の計測値**であり、現在値と一致しないことがある。現在値が必要なら計測すること。
 >
@@ -188,7 +188,7 @@
 
 ### weekly-review 周辺の決定論層テスト
 
-> **動機**: weekly-review に足した決定論層 (workspace-hygiene-scan / 7 レポート統合 / 昇格検査履歴) は instruction 層に散っており、**壊れても次の週次実行まで気づかない**。[#401](https://github.com/aloekun/claude-code-hook-test/pull/401) の scan は `2>/dev/null` でエラーを握り潰しており、失敗と 0 件を判別できなかった (指摘を受けて修正済みだが、回帰テストが無い)。
+> **動機**: weekly-review に足した決定論層 (workspace-hygiene-scan / 7 レポート統合 など) は instruction 層に散っており、**壊れても次の週次実行まで気づかない**。[#401](https://github.com/aloekun/claude-code-hook-test/pull/401) の scan は `2>/dev/null` でエラーを握り潰しており、失敗と 0 件を判別できなかった (指摘を受けて修正済みだが、回帰テストが無い)。
 >
 > **統合した提案 (4 件)**: scan 失敗と 0 件の区別 / aggregate-weekly の 7 レポート読み取り / 複数不採用理由の re-evaluation / parser 境界 3 件の regression 化 (#401 Tier2 #1・#3・#4、#404 Tier2 #1)。
 >
@@ -199,7 +199,7 @@
 #### 設計決定 (案)
 
 - parser 境界 3 件 (`+` 必須化 / 入れ子 brace 拒否 / 列欠落 panic) は `lib-ledger` に既存テストがあるので、**抜けている境界だけ足す**
-- scan 失敗の区別は instruction 内 bash が対象で Rust のテスト対象が無い。**検証対象を決める作業から始まる**（「判断留保キーワード検査の回帰テスト」「昇格不適格判定の『両経路記載』を決定論化するかを判断する」と同じ構図）— shell の単体テスト基盤を作るか、検査自体を exe へ寄せるかを判断する
+- scan 失敗の区別は instruction 内 bash が対象で Rust のテスト対象が無い。**検証対象を決める作業から始まる**（「判断留保キーワード検査の回帰テスト」と同じ構図）— shell の単体テスト基盤を作るか、検査自体を exe へ寄せるかを判断する
 
 #### 作業計画
 
@@ -384,37 +384,6 @@ finding_id 埋込の方針が未決 (現状維持か統一か)
 
 前提タスク (決定論層の実装先確定) 待ち
 
-### 昇格不適格判定の「両経路記載」を決定論化するかを判断する (出典: PR #400 Tier2 #2)
-
-> **動機**: CodeRabbit 指摘 (#400 の 1 件目 / 3 件目) — 採用は docs-only / cargo-test の **2 経路 OR** なので、片経路の失敗だけでは不適格を証明できない。#400 で「両経路分の基準番号または非適用理由」を必須化したが、これも instruction 層の規約で機械強制が無い。§ 昇格検査履歴 は一度記帳すると基準変更まで再評価されないため、**片経路だけの理由で記帳された順位は恒久除外**になる。
->
-> **本タスクの位置づけ**: レポートは新規テストファイルでの「OR/AND ロジック網羅テスト」を提案しているが、**昇格判定を行う Rust 実装は存在しない** (facet LLM + 人間の判断)。したがって「判定ロジックのテスト」は書けない。決定論化しうる対象は判定そのものではなく**記帳の形式** — § 昇格検査履歴 の各行の理由が両経路に言及しているかの検査である。これはレポート Tier1 #1 (様子見、誤検出率の検証待ち) と同じ対象であり、**両者は統合して扱う**。
->
-> **参照**: `.claude/feedback-reports/400.md` Tier 2 #2 および Tier 1 #1、[docs/claude-code-web-tasks.md](claude-code-web-tasks.md) § 昇格検査履歴
->
-> **実行優先度**: 🔧 **Tier 2** — Severity High / Frequency Medium / Effort S-M / Adoption Risk None。
-
-#### 設計決定 (案)
-
-- 検査対象は § 昇格検査履歴 の table 行の「対象外の理由」セル。両経路 (`docs-only` / `cargo-test`) への言及が揃っているかを見る
-- 誤検出率が読めないため、**実装前にサンプリング検証を行う** (レポート Tier1 #1 自身が前提として挙げている)
-- **「決定論層を作らない」も正規の出口**。その場合は negative result を `docs/dev-conventions.md` へ永続化する (spike 見送りの永続化 convention に従う)。§ 昇格検査履歴 はまだ 1 行も記帳されていないため、初回記帳の実物を見てから判断する方が精度が高い
-
-#### 作業計画
-
-- [ ] 次回 `/weekly-review` の初回記帳を待ち、実際の理由セルの書かれ方をサンプルとして得る
-- [ ] 両経路言及の検出を regex で書いた場合の誤検出率を、そのサンプルで見積もる
-- [ ] 採否を決める (実装する / negative result として見送る)
-- [ ] 実装する場合は fixture テストを同時に置く
-
-#### 完了基準
-
-- 実装するか見送るかが根拠つきで決まり、いずれの場合も記録が残る (実装 = 検査 + fixture、見送り = dev-conventions.md への negative result)
-
-#### 詰まっている箇所
-
-初回の記帳実績待ち (次回 `/weekly-review` で発生する)
-
 ### push-runner の bookmark 不在を早期検出し fallback のノイズを除去する (出典: PR #400 Tier2 #3)
 
 > **動機**: #400 のセッションで実際に発生 — 新規ブランチの初 push で `pnpm push` が exit 7 (`push 可能な bookmark がありません`) で中断した。パイプラインは pre_checks 段階で止まるため実害は小さいが、ユーザーが受け取るのは「push が失敗した」という結果である。
@@ -450,7 +419,7 @@ finding_id 埋込の方針が未決 (現状維持か統一か)
 
 > **動機**: #400 の CodeRabbit 指摘は 3 箇所すべてが**同じ欠陥**を指していた — 複数経路の OR で「どれも駄目」と結論するのに、片方の経路しか検査していない。台帳側には書式規約を入れたが、それは台帳固有の記述であり、同型の判断は他の場所でも起きうる。
 >
-> **本タスクの位置づけ**: 「昇格不適格判定の『両経路記載』を決定論化するかを判断する」の自動検出が様子見の間、**人手ガイドとして機能する**。自動検出を見送った場合は本 convention が恒久的な担保になる。
+> **本タスクの位置づけ**: 対だった自動検出タスク (順位 449「昇格不適格判定の『両経路記載』を決定論化するかを判断する」) は、検査対象だった台帳 § 昇格検査履歴 の廃止により 2026-08-16 に削除した。**本 convention は単独で成立する** — OR の不成立を片経路だけで主張する誤りは台帳の外でも起きるため、恒久的な担保として残す。
 >
 > **参照**: `.claude/feedback-reports/400.md` Tier 3 #1
 >
@@ -541,3 +510,93 @@ finding_id 埋込の方針が未決 (現状維持か統一か)
 #### 詰まっている箇所
 
 なし
+
+## 週次レビュー由来 (2026-08-15 実行、調査で判明した機構の欠陥)
+
+> **由来**: 2026-08-15 の週次レビュー ([ADR-031](adr/adr-031-weekly-review-pipeline.md)) 実行時に、findings とは別に**パイプライン自身の欠陥**が 2 件見つかった。どちらも実行ログ (`.takt/runs/20260815-100604-weekly-review-2026-08-15/logs/`) の実測に基づく。findings 採用分は [docs/todo.md](todo.md) § 週次レビュー採用 (2026-08-15) 側にある。
+
+### weekly-review facet の出力言語を output contract に明記する
+
+> **動機**: 2026-08-15 の run で `review-todo-whole.md` が**ほぼ全文ハングルで出力された**。同 run の他 4 facet (architecture / security / simplicity / jj-robustness) は英語で、**日本語の facet は 1 つも無かった**。原因は退行ではなく、**言語指定がどこにも存在しないこと**である。
+>
+> **調査で確定した事実** (2026-08-15):
+>
+> - takt は `language: en | ja` の config key を持つ (`node_modules/takt/builtins/{en,ja}/config.yaml:7`)
+> - **本リポジトリに `.takt/config.yaml` が無い** → builtin default にフォールバックし `en` ロケールが選ばれている。実行ログの systemPrompt が `builtins/en/facets/personas/architecture-reviewer.md` の英語テキストそのままであることで確認済み
+> - `.takt/` 配下を `日本語|Japanese|language` で全文検索した結果、ヒットは `review-todo-whole.md:91` の日本語**例文**のみ。**instruction にも output contract にも言語指定は 1 つも無い**
+> - `takt --help` に `--language` 相当のオプションは無い
+> - `~/.claude/settings.json` の `"language": "Japanese"` は Claude Code 本体の設定で、takt が spawn する provider には伝播しない
+>
+> **本タスクの位置づけ**: 出力言語がモデル任せだと、レポートを読む人間 (日本語話者) が毎回言語ガチャを引くことになる。ハングル出力は今回たまたま可読だったが、facet が増えるほど当たりを引く確率が下がる。
+>
+> **参照**: `.claude/weekly-reviews/2026-08-15.md`、`.takt/facets/instructions/*.md` の § Output contract、[ADR-048](adr/adr-048-facet-findings-handoff-markdown-contract.md) (output-contract 標準化)
+>
+> **実行優先度**: 🚀 **Tier 1** — Severity Medium / Frequency High (毎週全 facet) / Effort XS / Adoption Risk None。
+
+#### 設計決定
+
+**`.takt/config.yaml` に `language: ja` を置く案は採らない。** ロケール全体が切り替わり、takt builtin の persona / policy / knowledge がすべて日本語版に差し替わる。今回の問題は「レポートの出力言語」だけであり、persona の文面まで動かすのは影響範囲が広すぎる (現行の英語 persona で 4 facet は期待どおり動いている)。
+
+採るのは **各 facet instruction の `## Output contract` 節に出力言語を明記する**方式。facet 単位で確実に効き、instruction 自体がリポジトリ管理下にあるため差分がレビューに乗る。
+
+#### 作業計画
+
+- [ ] 対象 facet を棚卸しする — weekly-review の 7 step (`review-simplicity-whole` / `review-security-whole` / `review-architecture-whole` / `review-todo-whole` / `review-jj-robustness-whole` / `file-length-watchlist` / `workspace-hygiene-scan`) + `aggregate-weekly`。他パイプライン (pre-push-review / post-pr-review / post-merge-feedback) の facet も同じ欠落を持つか確認し、範囲を決める
+- [ ] 各 `## Output contract` に「レポート本文は日本語で書く。コード識別子・パス・ADR 番号は原文のまま」を追記する
+- [ ] `aggregate-weekly` の findings.json は `description` / `proposal` の言語をどうするか決める (現状は英語。skill が `docs/todo.md` へ展開する際に翻訳しているため、日本語化すると翻訳工程が減る)
+- [ ] 次回 weekly-review の実走で全 facet が日本語で出ることを確認する (**instruction 変更は実走でしか検証できない** — [docs/dev-conventions.md](dev-conventions.md))
+
+#### 完了基準
+
+- weekly-review の全 facet レポートが日本語で出力される
+- 出力言語が instruction 上の明示的な契約になっており、モデルやロケール既定に依存しない
+
+#### 詰まっている箇所
+
+なし
+
+### 昇格候補集合の構築を決定論層へ移す — instruction による全件判定の強制は 2 回失敗している
+
+> **動機**: `review-todo-whole` facet の昇格候補チェックが、**2 週連続で同じ形で失敗している**。2026-08-13 は 164 件中約 50 件をサンプリングして「0 件」と報告。対策として instruction に全件判定を義務づけた (#399 / #400) が、2026-08-15 の run は **251 件中約 13 件しか判定せず**、残り約 238 件を未判定のまま「候補 0 件」と結論した。
+>
+> **調査で確定した事実** (2026-08-15、実行ログの実測):
+>
+> - **instruction は完全に届いていた** — 20,145 文字が渡り、`judge ALL of it — never sample` も、2026-08-13 の同一失敗を名指しした文も含まれていた
+> - **takt は予算制約を一切注入していない** — プロンプト全体を `token|budget|limit|max` で検索して 0 ヒット
+> - **打ち切られてもいない** — 実行フェーズは 2 分 37 秒 / iteration 1 回 / `status: "done"` で正常終了。同 run の security facet は 3 分 54 秒使っており、短くも長くもない普通の終わり方
+> - したがって facet が書いた「token 예산 부족 (~12,500 token 대 실제 공급량 부족)」は**モデルの作り話**で、実際には何の予算にも当たっていない
+> - 同 facet は台帳の事実も誤読している (順位 284 の `無人可` を `✅` と報告。台帳の現物は `—`)
+>
+> **本タスクの位置づけ**: `model: haiku` の facet に 251 件の全件判定を**指示文だけで強制**している構造そのものが原因。[ADR-042](adr/adr-042-rule-vs-mechanism-boundary.md) の区分でいえばこれは「ルール」であって「仕組み」ではなく、同じ層での再強化は 2 回とも失敗した。3 回目を同じ層で試す根拠が無い。
+>
+> **なぜ放置できないか**: 昇格検査は「`docs/todo-summary*.md` に溜まったタスク → 台帳 → 夜間ループ」の唯一の供給経路である。ここが詰まると台帳の `✅` (auto lane) は現在の 3 件から増えず、夜間ループの消化能力が構造的に頭打ちになる。
+>
+> **参照**: `.claude/weekly-reviews/2026-08-15.md`、`.takt/facets/instructions/review-todo-whole.md` Criterion 3-2、[ADR-042](adr/adr-042-rule-vs-mechanism-boundary.md)、[ADR-022](adr/adr-022-automation-responsibility-separation.md)、[docs/work-plan-nightly-lane-model.md](work-plan-nightly-lane-model.md) PR-5
+>
+> **実行優先度**: 🚀 **Tier 1** — Severity High / Frequency High (毎週) / Effort S / Adoption Risk Low。
+
+#### rescope (2026-08-16): LLM 全件判定と収束機構を廃止し、差集合の出力だけを残す
+
+lane モデル ([ADR-072](adr/adr-072-nightly-todo-loop.md) 決定 18) により、**昇格 = 人間の割り当て判断**と再定義された。週次レビューが出すべきものは判定結果ではなく**判断の材料**だけになったため、本タスクから以下が落ちる。
+
+- **LLM への基準適合判定の配布** — 誰を台帳へ載せるかは人間が決める。facet は件数を報告するだけ (instruction は 2026-08-16 に縮小済み)
+- **収支検証 (渡した件数 = 返ってきた件数)** — 判定させないので収支という概念が消える
+- **収束機構 (§ 昇格検査履歴 への記帳)** — 同 section は 2026-08-16 に廃止。毎回全順位から差集合を取り直すため、除外リストという状態を持たない
+
+**残るのは差集合の決定論的な出力 1 点のみ。** `docs/todo-summary.md` + `docs/todo-summary2.md` の全順位から台帳の現行タスク表に既載の順位を引き、markdown (順位・Tier・タイトル) で出す。`lib-ledger` は既に台帳パーサ (`parse_target_files` / `rank_lookup`) を持っており、順位 table 側のパーサを足せば完結する (work-plan PR-3 で同じパーサを別用途に足すため、PR-3 の後が楽)。
+
+#### 作業計画
+
+- [ ] `docs/todo-summary*.md` の順位 table パーサを `lib-ledger` に追加する (台帳パーサと同じく「曖昧さは停止側へ」= 列ずれ・重複順位は fail-closed)
+- [ ] 差集合を出力する決定論 step を作る。配置は weekly-review workflow の純機械 step (file-length-watchlist / workspace-hygiene-scan と同型、LLM 判断ゼロ) を第一候補とする
+- [ ] `review-todo-whole` の Criterion 3-2 を、その出力への参照に置き換える
+- [ ] weekly-review skill 側を、一覧を**提示するだけ**の形へ更新する (判定も記帳もしない。台帳への行追加はユーザー承認時のみ、lane は人間が付ける)
+
+#### 完了基準
+
+- 台帳未掲載の順位一覧が決定論的に出力され、`cargo test --workspace` が green
+- 次回 weekly-review の実走で、その一覧がレポートに現れる
+
+#### 詰まっている箇所
+
+- work-plan PR-3 (順位 table 存在照合ゲート) の summary パーサ実装待ち — 同じパーサを流用するため
diff --git a/docs/todo24.md b/docs/todo24.md
new file mode 100644
index 00000000..376beb23
--- /dev/null
+++ b/docs/todo24.md
@@ -0,0 +1,54 @@
+# TODO (Part 24)
+
+> **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
+>
+> **本ファイルの位置付け**: docs/todo23.md がファイルサイズ 52690 B (2026-08-16 時点、50KB = 51200 B の安定読み取り閾値超過) に到達したため、新規エントリは本ファイルに記録する (2026-08-16 新設、週次レビュー 2026-08-15 実行セッションで検出)。**新規エントリの追加先は本ファイル**。todo.md / todo3.md 〜 todo23.md の既存エントリは引き続き有効、相互に独立。
+>
+> **サイズ表記について**: 各記載は**その時点の計測値**であり、現在値と一致しないことがある。現在値が必要なら計測すること。
+>
+> **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
+
+---
+
+## 週次レビュー由来 (2026-08-15 実行セッション、findings 外の運用問題)
+
+> **由来**: 2026-08-15 の週次レビュー ([ADR-031](adr/adr-031-weekly-review-pipeline.md)) 実行と、その後の調査セッションで判明した問題のうち、**夜間 todo ループ ([ADR-072](adr/adr-072-nightly-todo-loop.md)) の設計変更に依存しないもの**を登録する。
+>
+> **夜間ループ側の改善は本ファイルに登録しない。** ブランチのライフサイクル 2 種・台帳条件 3 の廃止・順位 table 存在照合ゲート・lane モデルへの移行は [docs/work-plan-nightly-lane-model.md](work-plan-nightly-lane-model.md) が直接の作業指示になっており、todo エントリと二重管理しない (2026-08-16 ユーザー判断)。同計画書は全項目の完了時に自身を削除する一時文書である。
+>
+> 同セッションで登録済みの 2 件 ([docs/todo23.md](todo23.md) § 週次レビュー由来) — facet 出力言語の明記 / 昇格候補集合の決定論化 — は本ファイルには重複させない。
+
+### `review-todo-whole` facet の台帳読み取りが現物と食い違う — 報告の信頼性を担保する
+
+> **動機**: 2026-08-15 の run で、`review-todo-whole` facet が台帳の `無人可` 列を**誤読した**。順位 284 を `✅` と報告したが、[docs/claude-code-web-tasks.md](claude-code-web-tasks.md) の現物は `—` であり、しかも同ファイルの § 無人可としなかった…理由 表に 284 が条件 3 違反として明記されている。facet は**自分が読んだはずのファイルに書いてある反証を見落として**逆の報告を出した。
+>
+> **なぜ問題か**: 本 facet の Criterion 3 は「台帳の外の状態 (未マージブランチ・進行中 PR) を見ないと判定できない」ことを唯一の存在理由にしている。その報告が台帳の現物とすら一致しないなら、外部状態の報告も同じ精度で疑う必要がある。実際 2026-08-15 の run は条件 3 を 3 件「unverified」と正しく報告しており (workflow が `network_access: false` のため `gh` に届かない)、**正しい部分と誤った部分が同じレポートに混在していた**。読み手が現物と突き合わせない限り区別できない。
+>
+> **同根の問題**: 同 facet は昇格候補チェックでも 251 件中 13 件しか判定せず、「token 予算不足」という**実測と矛盾する理由**を書いている (実行 2 分 37 秒 / iteration 1 回 / 予算制約の注入なし)。
+>
+> **本タスクの位置づけ**: facet は `model: haiku` で動いている (`.takt/workflows/weekly-review.yaml`)。台帳のセル値のような**機械的に読める事実**を LLM に読ませていること自体が設計の問題で、`lib-ledger` が既に台帳パーサを持っている以上、決定論層へ寄せられる。
+>
+> **参照**: `.claude/weekly-reviews/2026-08-15.md`、`.takt/runs/20260815-100604-weekly-review-2026-08-15/reports/review-todo-whole.md` (Criterion 3-3 の表)、`.takt/workflows/weekly-review.yaml` (`model: haiku`)、`src/lib-ledger/`、[docs/work-plan-nightly-lane-model.md](work-plan-nightly-lane-model.md) PR-5
+>
+> **実行優先度**: 💎 **Tier 3** — 要否そのものが未確定 (下記 rescope)。判定材料が揃うまで着手しない。
+
+#### rescope (2026-08-16): 要否を PR-5 の後に再判定する
+
+lane モデルへの移行 ([ADR-072](adr/adr-072-nightly-todo-loop.md) 決定 18) で **facet が台帳について報告する範囲が大きく縮んだ**。本タスクが問題視した誤読 (順位 284 の `無人可` を `✅` と報告) は Criterion 3-3 の未マージブランチ走査に付随して出たもので、その走査自体を 2026-08-16 に撤去した。さらに Criterion 3-2 の全件判定も件数報告へ縮小し、[work-plan](work-plan-nightly-lane-model.md) PR-5 で決定論 exe の出力へ置き換わる。
+
+**したがって本タスクは「台帳セルの構造化データを facet へ渡す」から「PR-5 後に facet が台帳について何を報告しているかを見て、決定論化がまだ要るかを判定する」へ rescope する。** 縮小後に残るのは `✅` 行の `注意` 列の読み直し程度であり、それだけのために構造化データ経路を新設するのは割に合わない可能性が高い。**「不要」も正規の出口**で、その場合は理由を付して本エントリを削除する。
+
+#### 作業計画
+
+- [ ] PR-5 (台帳未掲載順位一覧の決定論出力 + facet 参照置き換え) の完了を待つ
+- [ ] 次回 weekly-review の実走レポートで、facet が台帳について報告した内容を確認する
+- [ ] 機械的に読める事実の誤報告が残っているかを判定する
+- [ ] 残っていれば `lib-ledger` の構造化出力を facet へ渡す経路を設計する。残っていなければ理由を付して本エントリを削除する
+
+#### 完了基準
+
+- 決定論化の要否が実走レポートの実物を根拠に決まり、実装するか削除するかのいずれかで決着している
+
+#### 詰まっている箇所
+
+- PR-5 と、その後の weekly-review 実走 1 回待ち
diff --git a/docs/todo3.md b/docs/todo3.md
index d227e2d4..d5d0691b 100644
--- a/docs/todo3.md
+++ b/docs/todo3.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo2.md がファイルサイズ約 50KB に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して PR #88 以降の新規エントリは本ファイルに記録した。本ファイルも PR #96 セッションで 50KB 接近のため、それ以降の新規エントリは [docs/todo4.md](todo4.md) へ。todo.md / todo3-23.md の既存エントリは引き続き有効、相互に独立。新セッションでは24つすべてを確認すること (todo.md / todo3-23.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
+> **本ファイルの位置付け**: docs/todo2.md がファイルサイズ約 50KB に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して PR #88 以降の新規エントリは本ファイルに記録した。本ファイルも PR #96 セッションで 50KB 接近のため、それ以降の新規エントリは [docs/todo4.md](todo4.md) へ。todo.md / todo3-24.md の既存エントリは引き続き有効、相互に独立。新セッションでは25つすべてを確認すること (todo.md / todo3-24.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo4.md b/docs/todo4.md
index 3d102d5e..6692653b 100644
--- a/docs/todo4.md
+++ b/docs/todo4.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo3.md がファイルサイズ約 50KB に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して新規エントリは本ファイルに記録していた。**本ファイルも 50KB に到達したため、PR #101 セッション以降の新規エントリは [docs/todo5.md](todo5.md) へ**。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo3-23.md の既存エントリは引き続き有効、相互に独立。新セッションでは24つすべてを確認すること (todo.md / todo3-23.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
+> **本ファイルの位置付け**: docs/todo3.md がファイルサイズ約 50KB に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して新規エントリは本ファイルに記録していた。**本ファイルも 50KB に到達したため、PR #101 セッション以降の新規エントリは [docs/todo5.md](todo5.md) へ**。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo3-24.md の既存エントリは引き続き有効、相互に独立。新セッションでは25つすべてを確認すること (todo.md / todo3-24.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo5.md b/docs/todo5.md
index cd926b3e..baa82a42 100644
--- a/docs/todo5.md
+++ b/docs/todo5.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo4.md がファイルサイズ約 50KB に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して PR #101 セッション以降の新規エントリは本ファイルに記録していた。**本ファイルも 67KB に到達したため、2026-05-09 に PR #101〜#109 由来の古い半分を [docs/todo7.md](todo7.md) へ分離した**。本ファイル残存は PR #110 以降のエントリのみ。新規エントリは [docs/todo6.md](todo6.md) へ。todo.md / todo3-23.md の既存エントリは引き続き有効、相互に独立。新セッションでは24つすべてを確認すること (todo.md / todo3-23.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
+> **本ファイルの位置付け**: docs/todo4.md がファイルサイズ約 50KB に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して PR #101 セッション以降の新規エントリは本ファイルに記録していた。**本ファイルも 67KB に到達したため、2026-05-09 に PR #101〜#109 由来の古い半分を [docs/todo7.md](todo7.md) へ分離した**。本ファイル残存は PR #110 以降のエントリのみ。新規エントリは [docs/todo6.md](todo6.md) へ。todo.md / todo3-24.md の既存エントリは引き続き有効、相互に独立。新セッションでは25つすべてを確認すること (todo.md / todo3-24.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo6.md b/docs/todo6.md
index c5e3d98e..539f82d8 100644
--- a/docs/todo6.md
+++ b/docs/todo6.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo5.md / 本ファイルが 50KB に到達 (PR #143 T3-#1) のため **新規エントリは [docs/todo8.md](todo8.md) へ移行**。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo3-23.md の既存エントリは引き続き有効、相互に独立。新セッションでは24つすべてを確認すること (todo.md / todo3-23.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
+> **本ファイルの位置付け**: docs/todo5.md / 本ファイルが 50KB に到達 (PR #143 T3-#1) のため **新規エントリは [docs/todo8.md](todo8.md) へ移行**。本ファイルは既存タスクの編集・完了削除専用。todo.md / todo3-24.md の既存エントリは引き続き有効、相互に独立。新セッションでは25つすべてを確認すること (todo.md / todo3-24.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo7.md b/docs/todo7.md
index 18771e7f..5f21d3e5 100644
--- a/docs/todo7.md
+++ b/docs/todo7.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo5.md がファイルサイズ 67KB に到達して Claude Code の読み取り安定性 (50KB 超で不安定化) を損なったため、2026-05-09 に **PR #101〜#109 由来の古い半分のタスクを本ファイルへ分離** した。todo5.md には PR #110 以降のタスクが残存。本ファイルは既存タスクの編集・完了削除専用、新規タスクは追加しない (新規エントリは [docs/todo6.md](todo6.md) へ)。todo.md / todo3-23.md の既存エントリは引き続き有効、相互に独立。新セッションでは24つすべてを確認すること (todo.md / todo3-23.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
+> **本ファイルの位置付け**: docs/todo5.md がファイルサイズ 67KB に到達して Claude Code の読み取り安定性 (50KB 超で不安定化) を損なったため、2026-05-09 に **PR #101〜#109 由来の古い半分のタスクを本ファイルへ分離** した。todo5.md には PR #110 以降のタスクが残存。本ファイルは既存タスクの編集・完了削除専用、新規タスクは追加しない (新規エントリは [docs/todo6.md](todo6.md) へ)。todo.md / todo3-24.md の既存エントリは引き続き有効、相互に独立。新セッションでは25つすべてを確認すること (todo.md / todo3-24.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo8.md b/docs/todo8.md
index 26366d83..d7153290 100644
--- a/docs/todo8.md
+++ b/docs/todo8.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo6.md がファイルサイズ 50KB に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して PR #143 T3-#1 採用時 = 2026-05-11 から新規エントリは本ファイルに記録していた。**本ファイルも 60KB に到達したため、PR #172 仕組み化方針切替セッション = 2026-05-25 以降の新規エントリは [docs/todo9.md](todo9.md) へ移行**。本ファイルは既存タスクの編集・完了削除専用。**新規エントリの現在の追加先は [docs/todo23.md](todo23.md)** (todo9 → todo10 → todo13 → todo14 → todo20 → todo21 → todo22 と移動してきた)。todo.md / todo3.md 〜 todo7.md / todo9.md 〜 todo23.md の既存エントリは引き続き有効、相互に独立。新セッションでは24つすべてを確認すること (todo.md / todo3-23.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
+> **本ファイルの位置付け**: docs/todo6.md がファイルサイズ 50KB に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して PR #143 T3-#1 採用時 = 2026-05-11 から新規エントリは本ファイルに記録していた。**本ファイルも 60KB に到達したため、PR #172 仕組み化方針切替セッション = 2026-05-25 以降の新規エントリは [docs/todo9.md](todo9.md) へ移行**。本ファイルは既存タスクの編集・完了削除専用。**新規エントリの現在の追加先は [docs/todo24.md](todo24.md)** (todo9 → todo10 → todo13 → todo14 → todo20 → todo21 → todo22 → todo23 と移動してきた)。todo.md / todo3.md 〜 todo7.md / todo9.md 〜 todo24.md の既存エントリは引き続き有効、相互に独立。新セッションでは25つすべてを確認すること (todo.md / todo3-24.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/todo9.md b/docs/todo9.md
index cea8dea8..fa61fcb9 100644
--- a/docs/todo9.md
+++ b/docs/todo9.md
@@ -2,7 +2,7 @@
 
 > **運用ルール** ([docs/todo.md](todo.md) と同一): 各タスクには **やろうとしたこと / 現在地 / 詰まっている箇所** を必ず書く。完了タスクは ADR か仕組みに反映後、このファイルから削除する。過去の経緯は git log で追跡可能。
 >
-> **本ファイルの位置付け**: docs/todo8.md がファイルサイズ 60KB に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して新規エントリは本ファイルに記録する (PR #172 仕組み化方針切替セッション = 2026-05-25)。todo.md / todo2.md 〜 todo8.md の既存エントリは引き続き有効、相互に独立。**2026-06-06 分割**: 本ファイルが 75KB / 890 行に到達したため、PR-specific follow-up entries (順位 157, 160-173) を [docs/todo11.md](todo11.md) に分離。残置: 既存ルール仕組み化バンドル (順位 146-151) + 週次レビュー拡張 (順位 152-154)。新セッションでは24つすべてを確認すること (todo.md / todo3-23.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
+> **本ファイルの位置付け**: docs/todo8.md がファイルサイズ 60KB に到達したため、Claude Code の読み取り安定性 (50KB 超で不安定化) を考慮して新規エントリは本ファイルに記録する (PR #172 仕組み化方針切替セッション = 2026-05-25)。todo.md / todo3.md 〜 todo8.md の既存エントリは引き続き有効、相互に独立。**2026-06-06 分割**: 本ファイルが 75KB / 890 行に到達したため、PR-specific follow-up entries (順位 157, 160-173) を [docs/todo11.md](todo11.md) に分離。残置: 既存ルール仕組み化バンドル (順位 146-151) + 週次レビュー拡張 (順位 152-154)。新セッションでは25つすべてを確認すること (todo.md / todo3-24.md / todo-summary.md / todo-summary2.md。todo2.md は 2026-08-12 退役)。
 >
 > **推奨実行順序**: 全タスク横断のサマリーは [docs/todo-summary.md](todo-summary.md#recommended-order-summary) を参照。
 
diff --git a/docs/work-plan-nightly-lane-model.md b/docs/work-plan-nightly-lane-model.md
new file mode 100644
index 00000000..6c02ff8d
--- /dev/null
+++ b/docs/work-plan-nightly-lane-model.md
@@ -0,0 +1,257 @@
+# 作業計画書: 夜間 todo ループの lane モデル移行 (一時文書)
+
+> **本ファイルは一時文書である。** 下記「完了チェックリスト」の全項目が完了した時点で、**本ファイル自身を削除する**こと (最後の実装 PR に同梱してよい)。恒久的な決定はすべて ADR / 台帳 / dev-conventions に記録してから消す — 本ファイルにしか書かれていない決定を残したまま削除してはならない。
+>
+> **読者**: 実作業を行う Claude (Opus)。本ファイルだけで作業できるように書いてある。前提知識は [ADR-072](adr/adr-072-nightly-todo-loop.md) (夜間ループ)、[ADR-031](adr/adr-031-weekly-review-pipeline.md) (週次レビュー)、[docs/claude-code-web-tasks.md](claude-code-web-tasks.md) (台帳)。
+>
+> **作成**: 2026-08-16。2026-08-15 の週次レビュー実行で発覚した問題群 (下記 § 背景) に対し、ユーザーが方針を確定した。
+
+---
+
+## 背景 — なぜこの作業をするか
+
+### 発覚した問題 (2026-08-15〜16 のセッションで実測により確定)
+
+1. **週次レビューの昇格検査が 2 週連続で機能しなかった**。`review-todo-whole` facet (haiku) に 251 件の全件判定を指示文だけで強制していたが、13 件しか判定せず「候補 0 件」と報告 (前週は 164 件中約 50 件サンプリング)。instruction は完全に届いていた (実行ログで確認、20,145 字) が無視された。instruction 再強化 (#399/#400) は同じ層への対処で 2 回とも失敗。
+2. **facet が台帳を誤読** (順位 284 の 無人可 を `✅` と報告、現物は `—`)。
+3. **facet の出力言語が不定** (2026-08-15 の run で `review-todo-whole` がほぼ全文ハングル、他 4 facet は英語、日本語ゼロ)。原因は言語指定の不在 (`.takt/config.yaml` が無く en builtin にフォールバック。instruction にも contract にも言語指定なし)。
+4. **台帳の条件 3 (重複の恐れがない) と ADR-072 決定 3 が同じ状態を逆に解釈**。決定 3 は `claude/nightly-<順位>` ブランチを「着手済みマーカー」として扱い再選択を防ぐが、条件 3 は同じブランチを「無人可マークの無効化理由」として降格を要求する。この矛盾から誤った週次 finding (WR-2026-08-13-T01/T02) が採用された。T01 は台帳の明文規定 (「削除するのはマージした順位だけ」) に矛盾し、実行すると未完了タスク 3 件が台帳から消える。
+5. **人間が台帳タスクを手で実装・マージした場合の後始末が漏れる** (実績 4 件中 2 件失敗)。台帳の行が残ると夜間ループが再実装しうる。
+6. **verify 段で失敗した run はブランチも PR も残さないため、翌晩同じタスクが再選択される** (先頭独占ループ)。
+
+### ユーザーが確定した設計方針 — lane モデル (担当権管理)
+
+問題の根本は「タスク割り振り」の問題を「分散システムの状態管理」として解いていたこと。GitHub 上の副作用 (ブランチ・PR・マージ履歴) から担当と進捗を推測するのをやめ、**台帳が担当を直接表現する**:
+
+```text
+台帳 = 担当割り当て表
+  無人可列 ✅ = auto  (夜間ループに割り当て)
+  無人可列 —  = human (ユーザー + Claude Code に割り当て)
+  ※ 台帳の表形式は変更しない。意味論の再定義のみ
+
+ブランチ (claude/nightly-<順位>) = 作業中マーカー (完了マーカーではない)
+完了 = PR に同梱された台帳削除がマージされること (実装済み: cli-ledger-cleanup --apply)
+失敗 = マーカーを残して人間確認へ。再投入は人間の明示操作
+```
+
+**核心となる運用原則** (ADR 改訂に反映すること):
+
+- 無人可 (= lane) の判断は**人間だけ**が行う。夜間 worker は auto の先頭 1 件を取って実行するだけで、「本当に簡単か」「重複しないか」を再審査しない
+- **競合は検出するのではなく、競合する割り当てをしない**。人間が auto を付けたタスクは夜間ループの所有物。人間が引き取るなら lane を human に変える
+- **失敗したタスクを無変更で自動再投入しない**。agent が完遂できなかったタスクは人間確認へ戻す。再投入 (lane を auto のまま維持しブランチ/マーカーを削除) は人間の意思表示
+- インフラ障害 (network / gh / clone) は implement 前に red で落ちマーカーを作らない → 翌晩自然に再試行。**transient / タスク不適合の分類は run の構造で解決し、分類器は作らない**
+
+### 確定済みの個別決定 (ユーザー承認済み、再ヒアリング不要)
+
+| 決定 | 内容 |
+|---|---|
+| verify 失敗の扱い | 人間確認へ戻す (空 ref マーカー方式、下記 PR-4) |
+| 台帳条件 3 | 廃止 (代替ゲート不要 — 割り当て規律で防ぐ) |
+| Phase 4 展開先 | weekly-review skill を「preamble が指す現在の新規追加先 todoN.md」へ展開する形に変更 |
+| facet 出力言語 | 各 output contract に**直書き 1 行** (参照形はプロンプトに載らず効かないため不採用)。由来を dev-conventions.md に記録 |
+| 選出システム | **既存実装を流用** (lib-ledger / cli-nightly-task-select)。作り直さない |
+
+### 検討して捨てた案 (negative result として ADR-072 改訂に記録すること)
+
+| 案 | 捨てた理由 |
+|---|---|
+| `claude/nightly-state` ブランチ + 最終試行日順選択 | 自動再投入をやめたため試行履歴・順序変更が不要になった |
+| 対象ファイル重なり走査 (他経路重複の検出ゲート) | 「競合する割り当てをしない」が原則。検出は割り当て規律の代替にならない |
+| Ledger-Rank trailer の未マージブランチ走査 | trailer は任意記入で、実例 (順位 284 の `claude/select-next-task-a9aiam`) を検出できない |
+| 失敗理由の分類器 | インフラ障害は構造上マーカーを作らないため、分類は run の構造で足りる |
+| 台帳への選択時直 push (試行日列) | ガード対象ファイルへの自律書き込み経路の新設。ADR-070 で同型案が却下済み |
+| 再挑戦上限 N 回 | 再投入が人間操作になったため上限管理が不要 |
+
+---
+
+## 共通ルール (本計画書の PR-1〜PR-5 に適用)
+
+> **適用範囲は本計画書が指示する PR (人間 + Claude Code の interactive セッションが作るもの) に限る。** 夜間ループが `claude/nightly-*` から自動作成する PR は [ADR-052](adr/adr-052-autonomy-execution-boundary-classes.md) 原則 1・2 と [ADR-072](adr/adr-072-nightly-todo-loop.md) 決定 15 に従い、**承認はマージ 1 点**である。本節の承認要件を夜間ループへ適用すると lane が止まる ([#409](https://github.com/aloekun/claude-code-hook-test/pull/409) の CodeRabbit 指摘。ADR-028 原則 1 が「interactive セッションは人間ゲート / 自律 actor は事前分類」と分けているとおり)。
+
+- **PR 作成前にタイトル・ボディをユーザーへ提示し明示承認を得る** (ADR-028、interactive セッション限定)。push は `pnpm push` (takt レビュー経由)、PR 作成は承認後に `pnpm prepare-pr-body` → `pnpm create-pr` (複数行 body は `--body-file` 経路)
+- 各 PR の完了時、対応する `docs/todo*.md` のエントリを削除する (運用ルール「完了タスクは削除」)
+- docs 変更は `pnpm lint:docs` と markdownlint が clean であること。Rust 変更は `cargo test --workspace` green + 該当 crate の `cargo clippy`
+- workflow (`nightly-todo.yml`) の変更は実走でしか検証できない ([dev-conventions](dev-conventions.md))。`workflow_dispatch` (可能なら dry_run) で観測してから完了と報告する
+- 本ファイルの下記チェックリストは、各 PR の作業に同梱して更新してよい
+
+---
+
+## PR-1 (docs): lane モデルの決定化 + 撤回 + 登録整理
+
+**注意**: 2026-08-16 時点の working copy に未コミットの docs 変更が既にある (todo24.md 新設、todo23.md への 2 件登録、todo.md preamble 更新、todo3〜11/22/23 の数詞・ポインタ整合修正)。これらは本 PR に同梱する。`jj st` で現状を確認してから着手すること。
+
+### 1-a. ADR-072 の改訂
+
+新しい決定 section (番号は既存の続き) として以下を記録する:
+
+- **台帳 = 担当割り当て (lane モデル)**: 無人可列の意味論を「auto / human の担当割り当て」と再定義。無人可の判定条件から条件 3 を削除 (条件 1・2 は人間が割り当て時に使う判断基準として残る)。夜間 worker はマークの再審査をしない
+- **ブランチ = 作業中マーカー**: 完了マーカーではないことを明記。完了は台帳削除の PR 同梱 (既存決定) が表現する
+- **agent 実行後の停止はすべて人間確認へ**: implement 完了後に publish へ到達しなかった run (verify 失敗 / ledger-completion 未完了 / guard deny / 空 diff) は、空 ref マーカー `claude/nightly-<順位>` (base commit を指す) を残して停止する。マーカーがある間その順位は再選択されない (既存の決定 3 の除外がそのまま効く)。implement **前**の停止 (kill-switch / 背圧 / タスク無し / インフラ障害) はマーカーを作らない → 自然再試行。この境界が transient / タスク不適合の分類を構造で代替する
+- **再投入は人間の明示操作**: (a) 人間が引き取る → 台帳の `✅` を `—` へ変更しマーカー/ブランチを削除、(b) 仕様を直して再投入 → `✅` のままマーカー/ブランチを削除。close した nightly PR のブランチは自動掃除 (PR-4) が削除し、lane が auto のままなら再選択される — **lane を auto のまま残す = 再投入の意思表示**
+- **決着済み PR ブランチの自動掃除**: 夜間ループが起動時に、決着済み (closed / merged) の PR に紐づく `claude/nightly-*` ブランチを削除する。PR の無いブランチ (= 失敗マーカー) は対象外
+- § 検討して捨てた案 (上記表) を negative result として記録
+- § 残課題から「失敗した run の学習が無い」を削除 (仕様化されたため)
+
+### 1-b. ADR-052 の追記
+
+自律 actor の操作分類に「自ブランチ (claude/nightly-\*) の削除」「空 ref の作成 (失敗マーカー)」を追加。どちらも claude/\*\* 空間内で、PR が紐づくブランチは成果物が PR 上に残り GitHub の Restore branch で復元可能 = commitment 点の侵犯に当たらない旨を記す。
+
+### 1-c. 台帳 (docs/claude-code-web-tasks.md) の改訂
+
+- § 自律実行可否の 2 段階分類: 条件 3 を削除し 2 条件にする。lane モデルの意味論 (✅ = 夜間ループの所有物、人間が触るなら lane を変える) を追記
+- § 夜間ループでマージしたタスクの後始末 の近くに close 時の運用を追記: 「nightly PR を close するとき、引き取るなら `✅` → `—` に変更する。`✅` のまま残す = ブランチ掃除後に自動再投入される意思表示」
+- § ライフサイクル 定期更新（週次） の項 2 (昇格候補の全件判定) と項 3 (条件 3 の再確認) を lane モデルに合わせて縮小: 昇格 = 人間の割り当て判断であり、週次はその材料 (台帳未掲載の順位一覧、PR-5 で決定論化) を提供するのみ。§ 昇格検査履歴 は廃止する (表が空のまま。収束機構は不要になった旨を記して section を削除するか、廃止注記を残す — 実行者判断)
+
+### 1-d. facet instruction の改訂 (.takt/facets/instructions/review-todo-whole.md)
+
+- Criterion 3-3 (無人可マークの条件 3 再検査 = 未マージブランチ/PR の走査) を撤去
+- Criterion 3-2 (昇格候補の全件判定 + 検査履歴記帳の義務) を縮小: 全件判定・両経路理由・記帳の義務を撤去し、「台帳未掲載の順位の存在を件数レベルで報告する (判定はしない。割り当ては人間の判断)」程度に留める。PR-5 で決定論出力に置き換わる予定と注記
+
+### 1-e. 誤採用 finding の撤回
+
+[docs/todo.md](todo.md) § 週次レビュー採用 (2026-08-13) から以下 2 エントリを削除する:
+
+- 「台帳の ✅無人可 5 行を condition 3 違反により — へ降格 (WR-2026-08-13-T02)」— 前提消滅 (対象ブランチは 2026-08-15 に削除済み、順位 216/239 は完了済み) + 条件 3 自体が本 PR で廃止
+- 「台帳 Batch 1 の closed-without-merge 行を棚卸し履歴へ移動し、in-flight を明示 (WR-2026-08-13-T01)」— 台帳の明文規定「削除するのはマージした順位だけ」と矛盾。実行すると未完了 3 タスクが台帳から消える
+
+撤回の理由を PR description に記す (採用済み finding を実行せず消したことが後から追える必要がある)。
+
+### 1-f. todo エントリの整理
+
+- [docs/todo24.md](todo24.md) の「週次レビューが誤って採用した台帳 finding 2 件を撤回する」→ 本 PR で実施するため削除
+- [docs/todo24.md](todo24.md) の「review-todo-whole facet の台帳読み取りが現物と食い違う」→ lane モデルで Criterion 3 が縮小されるため、「PR-5 の facet 改訂後に残る報告範囲を見て要否を再判定する」旨に rescope
+- [docs/todo23.md](todo23.md) の「昇格候補集合の構築を決定論層へ移す」→ rescope: LLM 全件判定・収束機構 (昇格検査履歴) は廃止。残るのは「台帳未掲載の順位一覧を決定論的に出す」のみ (PR-5)
+- 夜間ループ改善 (PR-3/PR-4 相当) のタスクエントリは登録しない — 本計画書が直接の作業指示となるため二重管理しない
+
+### PR-1 完了基準
+
+- ADR-072 / ADR-052 / 台帳 / facet instruction / todo.md が上記どおり改訂され、`pnpm lint:docs` + markdownlint clean
+- 本計画書 (このファイル) が同 PR に含まれてリポジトリに入る
+
+---
+
+## PR-2 (takt): facet 出力言語の直書き
+
+### 作業内容
+
+- `.takt/facets/instructions/` 配下の全 instruction (19 ファイル) の Output contract 節 (無ければ末尾) に 1 行追加: 「**レポート本文は日本語で書く。コード識別子・ファイルパス・ADR 番号・コマンドは原文のまま。**」
+- `aggregate-weekly` は findings.json の `description` / `proposal` も日本語とする旨を明記 (skill が todo へ展開する際の翻訳工程が減る)
+- [docs/dev-conventions.md](dev-conventions.md) に規約の由来を 1 箇所記録: 「takt facet の出力言語は各 instruction に直書きする (2026-08-15 の run で言語指定不在によりハングル出力が発生。参照形はプロンプトに載らず効かないため直書き。変更時は grep で全箇所を更新する)」
+
+### PR-2 完了基準
+
+- 全 instruction に言語指定行がある (`grep -L "日本語" .takt/facets/instructions/*.md` が空)
+- [docs/todo23.md](todo23.md) の「weekly-review facet の出力言語を output contract に明記する」エントリを削除
+- マージ後、次回 weekly-review 実走で全レポートが日本語であることを確認 (完了チェックリストの実走確認項目)
+
+---
+
+## PR-3 (実装・小): 順位 table 存在照合ゲート
+
+**目的**: 人間が台帳タスクを手で実装・マージし後始末が漏れた場合 (実績 4 件中 2 件)、台帳に残った行を夜間ループが再実装するのを防ぐ。着手フローでは完了時に `docs/todo-summary*.md` の順位行が削除されるため、**順位 table からの消失 = 完了済み (または取り下げ) の機械的シグナル**になる。
+
+### 作業内容
+
+- `src/lib-ledger/` に「指定順位が summary markdown 群のいずれかの順位 table に存在するか」を返す関数を追加。既存の `removal.rs` (remove_summary_row) が summary table のパースを既に行っているので流用する。セル形 `| <順位> |` で照合 (裸の数字は行数等に誤マッチする — 既存実装の照合方針に合わせる)
+- `cli-nightly-task-select` に summary ファイルパスを渡す引数を追加 (**省略不可**。フラグ欠落 = 数えられなかった、は exit 2。決定 3 の `--exclude-ranks` と同じ設計)
+- 選択ループでの扱い: 候補順位が summary に**無い**場合、その順位を**選択せずスキップし、警告を stdout に出す** (「順位 N は台帳に残っているが順位 table に無い。後始末漏れか再採番。台帳の行を人間が確認すること」)。他の候補があれば続行する。summary ファイルが**読めない**場合は exit 2 (fail-closed、ADR-072 決定 2「曖昧さはすべて停止側へ」)
+- `nightly-todo.yml` の Select step に `master-ref/docs/todo-summary.md` と `master-ref/docs/todo-summary2.md` を渡す配線を追加
+- unit test: 存在する / 両ファイルに無い / ファイル不読 / 順位 table 以外の表 (棚卸し履歴等) にだけ数字がある場合に誤検知しない
+
+### 留意点
+
+- 順位の**再採番**でも同じ警告が出る (台帳が旧番号を指したまま)。誤検知ではなく台帳の staleness なので、警告文言はその可能性に触れること
+
+### PR-3 完了基準
+
+- `cargo test --workspace` green、`workflow_dispatch` (dry_run) で警告経路とスキップ経路が動くことを観測
+
+---
+
+## PR-4 (実装・workflow): ブランチのライフサイクル 2 種
+
+**対象ファイル**: [.github/workflows/nightly-todo.yml](../.github/workflows/nightly-todo.yml)、必要なら `src/cli-stale-branch-scan/`
+
+### 4-a. 失敗マーカー (agent 実行後の停止 → 人間確認)
+
+- implement 完了後に publish へ到達しない停止 (verify 失敗 / ledger-completion 未完了 / guard deny / 空 diff) が起きたら、**空 ref `claude/nightly-<順位>` を base commit (agent 起動前に記録済みの `git -C work rev-parse HEAD`) に作成**する。実装は `gh api -X POST /repos/{owner}/{repo}/git/refs` 1 回 (App token 使用。コードは push しない)
+- run の色: 決定 10 の分類に従い green のまま、ただし `[NIGHTLY_SKIP]` とは**別のマーカー** (例: `[NIGHTLY_HANDOFF]`) で Report outcome に出す。報告には順位と次の操作 (「引き取る → 台帳 ✅→— + ブランチ削除 / 再投入 → ブランチ削除のみ」) を含める
+- マーカーがある限り決定 3 の除外 (`git ls-remote` による `claude/nightly-<順位>` の存在確認) がそのまま効くため、**selector 側の変更は不要**
+
+### 4-b. 決着済み PR ブランチの自動掃除
+
+- タスク選択の**前**に、`claude/nightly-*` ブランチのうち「紐づく PR がすべて決着済み (**closed または merged**)」のものを削除する step を追加
+- **merged を除外しない** (2026-08-16 修正、[#409](https://github.com/aloekun/claude-code-hook-test/pull/409) の CodeRabbit 指摘)。初版は「merged はブランチ削除済みが通常」として対象外にしていたが、マージ時のブランチ消し忘れと台帳行の残存が重なると、その順位が決定 3 の除外に永久に掛かり続ける
+- **PR の無いブランチは削除しない** (失敗マーカーを消さないため)。**境界は「PR があるか」の 1 点だけ**にする。この判定は `cli-stale-branch-scan` が既に持っている (「PR が 1 件も無いブランチは提案対象外」)。同 crate に機械可読出力 (削除可能ブランチを 1 行 1 件、`claude/nightly-*` に限定するフィルタ付き) を追加して workflow から消費するのを推奨 — shell での PR 状態パースは回帰テストの場が無い (ADR-072 決定 1 の rationale と同じ)
+- **回帰テスト**: 「merged だがブランチが残っている」ケースが削除対象になること、「PR が 1 件も無いブランチ」が対象外のままであることの 2 件を unit test で固定する
+- 削除は App token で `git push origin --delete` (job の `GITHUB_TOKEN` は read-only のため不可)
+
+### 4-c. App token の発行タイミング
+
+- 現在は publish 直前に 1 回 mint (寿命 1h、agent 最大 60 ターンのため)。掃除 (選択前) と失敗マーカー (verify 後) にも token が要る
+- 推奨: **掃除用に job 冒頭で 1 回、publish/マーカー用に implement 後で 1 回の計 2 回 mint**。失敗マーカーの作成は publish 用 mint の位置 (verify の直後) で間に合う
+
+### 4-d. PR body への close 時案内
+
+- nightly PR の body テンプレートに 1 行追加: 「close する場合: 引き取るなら台帳の `✅` を `—` へ。`✅` のまま close するとブランチ掃除後に自動で再投入されます」
+
+### PR-4 完了基準
+
+- `workflow_dispatch` で (a) 掃除 step が対象なし時に無害に通過、(b) 失敗マーカー経路 (可能なら意図的に verify を落とす dry-run 相当) の動作を観測。フル経路の確認は次回 schedule 実走に委ねてよい (完了チェックリストに実走確認項目あり)
+
+---
+
+## PR-5 (実装・rescope 済み): 週次レビューの割り当て補助
+
+**旧計画 (LLM 全件判定 + 収束機構) は廃止済み。** 残る作業は小さい。
+
+### 作業内容
+
+- 決定論 exe: `docs/todo-summary.md` + `docs/todo-summary2.md` の全順位から台帳の現行タスク表に載っている順位を引いた**差集合 (台帳未掲載の順位一覧)** を出力する。`lib-ledger` の既存パーサ + PR-3 で足した summary パーサを流用。出力は markdown (順位・Tier・タイトル程度)
+- 配置: weekly-review workflow の純機械 step (file-length-watchlist / workspace-hygiene-scan と同型、LLM 判断ゼロ) を推奨。skill 決定論層 (stale-branch-scan 方式) でも可 — ネットワーク不要なので workflow 内で成立する
+- 用途は**人間の割り当て判断の材料**。skill はこの一覧を提示するだけで、判定も記帳もしない (lane の付与は人間)
+- facet `review-todo-whole` の Criterion 3-2 相当をこの出力への参照に置き換える
+- 完了後、[docs/todo23.md](todo23.md) の rescope 済みエントリ (昇格候補集合の決定論化) を削除。[docs/todo24.md](todo24.md) の構造化データ entry は、この時点の facet の報告範囲を見て要否を再判定し、不要なら理由を付して削除
+
+### PR-5 完了基準
+
+- `cargo test --workspace` green。次回 weekly-review 実走で一覧が出力されることを確認
+
+---
+
+## skill リポ作業 (本リポジトリ外)
+
+weekly-review skill (`~/.claude/skills/weekly-review/` — 実体は `$CLAUDE_SKILLS_REPO` で管理) に対して:
+
+1. **Phase 4 の展開先変更**: 採用 findings の展開先を `docs/todo.md` 固定から「`docs/todo.md` preamble が指す**現在の新規追加先** (2026-08-16 時点では todo24.md)」に変更する。todo.md は 47.8KB で編集専用と定義されており、固定のままだと次回採用時に 50KB ゲートが skill 実行中に発火する。展開先ファイルが 50KB 超過している場合の挙動 (次ファイル新設 or ユーザーへ報告) も定める
+2. **台帳昇格フローの縮小**: Phase 3 の「台帳昇格候補の扱い (必須ステップ)」と Phase 4 の「§ 昇格検査履歴へ記帳する (必須ステップ)」を lane モデルに合わせて縮小 — PR-5 の決定論一覧を提示し、台帳への行追加はユーザーが承認した場合のみ (無人可=`—` 固定は維持)。全件判定の収支検査・両経路理由・記帳の手順を削除
+3. 反映後 `/skill-sync-check` で同期状態を確認
+
+---
+
+## 実施順序と依存
+
+```text
+PR-1 (docs) → PR-2 (言語) → PR-3 / PR-4 (相互に独立、並行可) → PR-5
+skill リポ作業は PR-1 マージ後いつでも (PR-5 と独立)
+```
+
+- PR-1 が全決定の記録なので必ず先頭
+- PR-3 と PR-4 に順序依存はない (旧計画の state ブランチ依存は消滅)
+- PR-5 は PR-3 の summary パーサを流用するため PR-3 の後が楽
+
+---
+
+## 完了チェックリスト
+
+作業の進捗に応じて本節を更新すること (各 PR に同梱してよい)。
+
+- [x] PR-1: docs (ADR-072/052 改訂、台帳条件 3 廃止、facet Criterion 3-2/3-3 縮小、T01/T02 撤回、todo rescope、本計画書の同梱) — 2026-08-16 実施。計画外の追加 (ユーザー承認済み): (a) 順位 449「昇格不適格判定の『両経路記載』を決定論化」を削除 (検査対象の § 昇格検査履歴 廃止で前提消滅)、(b) 台帳 § 無人可としなかった理由 の順位 284 行を lane 表記へ更新 + 見出しから件数を除去、(c) 未採番だった詳細エントリ 3 件に順位 462-464 を採番、(d) **ADR-033 改訂** — 「順位 = 追記型 ID・優先度は Tier 列・再採番はしない・細粒度の順序は行の並びで表す」を明文化し、本文の順位参照禁止を緩和。帰結として順位 334 (本文順位番号 lint) を retire
+- [ ] PR-2: facet 出力言語の直書き + dev-conventions 記録 + todo23 エントリ削除
+- [ ] PR-3: 順位 table 存在照合ゲート (lib-ledger + selector + workflow 配線)
+- [ ] PR-4: 失敗マーカー + ブランチ自動掃除 + token 2 段化 + close 時案内
+- [ ] PR-5: 台帳未掲載順位一覧の決定論出力 + facet 参照置き換え + todo23/24 エントリ整理
+- [ ] skill リポ: Phase 4 展開先変更 + 昇格フロー縮小 + skill-sync-check
+- [ ] 実走確認 1: weekly-review 実走で全 facet レポートが日本語 (PR-2 の効果)
+- [ ] 実走確認 2: nightly schedule 実走 (または dispatch) で掃除 → 選択 → (成功なら PR / 失敗ならマーカー) の経路が設計どおり動く (PR-3/PR-4 の効果)
+- [ ] **本ファイル (docs/work-plan-nightly-lane-model.md) を削除する** — 上記すべて完了後。恒久的な決定がすべて ADR / 台帳 / dev-conventions に反映済みであることを確認してから消すこと