docs(weekly-review): 昇格追記の注意欄転記規則と検査履歴の基準番号書式を明文化する

.takt/facets/instructions/review-todo-whole.md

@@ -73,7 +73,9 @@ Check three things, in this order:
 
    **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.
 
-   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**, so the `/weekly-review` skill can record them into § 昇格検査履歴 and future runs stop re-examining them.
+   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 names the failing criterion** (`docs-only 基準 1–3` / `cargo-test 基準 1–3`, per the ledger's § 昇格検査履歴 書式規約), so the `/weekly-review` skill can record them into § 昇格検査履歴 and future runs stop re-examining them. A reason without a criterion number cannot be recorded — the ledger's re-evaluation on criteria changes filters by these numbers, so the skill treats such a 順位 as unjudged.
+
+   **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. 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.
 
    **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.

docs/claude-code-web-tasks.md

@@ -23,6 +23,8 @@
 
 3 は台帳だけでは判定できないため、定期棚卸し（→ § ライフサイクル）で確認する。**判定に迷ったら無人可にしない** — 誤って無人可にしたタスクは、夜間ループが人間の意図と違う実装で draft PR を作る形で失敗する。無人可にしなかったことによる損失は「Web セッションで人間が着手する」だけであり、非対称に軽い。
 
+**条件 1 の判定は「注意」欄のキーワード走査に依存する。** したがって本台帳へ行を追記する者（weekly-review skill の昇格追記を含む）は、詳細エントリ（`docs/todoN.md`）にある判断留保の記述 —「再選定」「着手時判断」「見積り」「検討」など人間が決める前提の語 — を要約で圧縮・省略せず「注意」欄へ転記しなければならない。転記が落ちると、詳細エントリでは判断が残っているタスクが台帳上は条件 1 を満たして見え、無人可判定（人間のマーク付与と週次レビューの再検査の両方）が構造的に盲目化する。
+
 マークは**人間が付ける**（ADR-022 の責務分離）。夜間ループは無人可マークの有無を機械的に読むだけで、自分でこの判定をしない。
 
 ## 採用タスク
@@ -184,6 +186,8 @@ cargo test で検証完結するが、新規 module / lint rule / 軽微リフ
 
 **書き手は `/weekly-review` skill**（ユーザー承認後）。facet は read-only なので自分では書けない（ADR-022）。**無人可マークと同様、行の削除や採否そのものは人間の判断**である。
 
+**「対象外の理由」の書式**: どの採用経路のどの基準で落ちたかを必ず含める（例: `cargo-test 基準 2 不適合 (Windows hook 発火が成功条件)`、`docs-only 基準 1・cargo-test 基準 1 とも不適合`。「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 方式との違いで、基準を触った回に本表を棚卸しすること。
 
 | 検査日 | 順位 | 対象外の理由 |