diff --git a/.takt/facets/instructions/review-todo-whole.md b/.takt/facets/instructions/review-todo-whole.md
index e059468..9a093e5 100644
--- a/.takt/facets/instructions/review-todo-whole.md
+++ b/.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 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.
+
+   **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.
 
    **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.
diff --git a/docs/claude-code-web-tasks.md b/docs/claude-code-web-tasks.md
index 6b6b3e7..86c791a 100644
--- a/docs/claude-code-web-tasks.md
+++ b/docs/claude-code-web-tasks.md
@@ -23,6 +23,10 @@
 
 3 は台帳だけでは判定できないため、定期棚卸し（→ § ライフサイクル）で確認する。**判定に迷ったら無人可にしない** — 誤って無人可にしたタスクは、夜間ループが人間の意図と違う実装で draft PR を作る形で失敗する。無人可にしなかったことによる損失は「Web セッションで人間が着手する」だけであり、非対称に軽い。
 
+**条件 1 の判定は「注意」欄のキーワード走査に依存する。** したがって本台帳へ行を追記する者（weekly-review skill の昇格追記を含む）は、詳細エントリ（`docs/todoN.md`）にある判断留保の記述 —「再選定」「着手時判断」「見積り」「検討」など人間が決める前提の語 — を要約で圧縮・省略せず「注意」欄へ転記しなければならない。転記が落ちると、詳細エントリでは判断が残っているタスクが台帳上は条件 1 を満たして見え、無人可判定（人間のマーク付与と週次レビューの再検査の両方）が構造的に盲目化する。
+
+転記する原文が上記の例示語をどれも含まない同義表現（「未定」「どちらでもよい」「複数案あり」等）の場合は、**正準タグを付して「着手時判断: <原文>」の形で転記する**。キーワード走査は例示語しか見ないため、タグ無しの同義表現は判断が残っているのに条件 1 をすり抜ける。
+
 マークは**人間が付ける**（ADR-022 の責務分離）。夜間ループは無人可マークの有無を機械的に読むだけで、自分でこの判定をしない。
 
 ## 採用タスク
@@ -184,6 +188,8 @@ cargo test で検証完結するが、新規 module / lint rule / 軽微リフ
 
 **書き手は `/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 方式との違いで、基準を触った回に本表を棚卸しすること。
 
 | 検査日 | 順位 | 対象外の理由 |