diff --git a/.takt/facets/instructions/review-todo-whole.md b/.takt/facets/instructions/review-todo-whole.md index bb723c7..e059468 100644 --- a/.takt/facets/instructions/review-todo-whole.md +++ b/.takt/facets/instructions/review-todo-whole.md @@ -65,7 +65,15 @@ Check three things, in this order: 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. - **This check is MANDATORY and its result must appear as a dedicated report section `## 昇格候補 (promotion candidates)` — even when the answer is zero.** A zero-candidate result must state 0 件 together with what was examined (how many 順位 rows each summary file contributed, how many were excluded as already listed in the ledger, and how many detail entries were read and rejected against which criterion). 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. + **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. + + **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. + + **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. + + 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. 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 4fa7885..6b6b3e7 100644 --- a/docs/claude-code-web-tasks.md +++ b/docs/claude-code-web-tasks.md @@ -176,6 +176,20 @@ cargo test で検証完結するが、新規 module / lint rule / 軽微リフ --- +## 昇格検査履歴 + +週次レビューの昇格候補チェック（→ [§ 定期更新（週次）](#定期更新週次) 2）で **「検査したが本台帳の採用基準を満たさない」と判定した順位**を記録する。次回以降の検査はここに載っている順位を除外し、**残り全件**を判定する。 + +**なぜ記録が要るか**: この記録が無いと、検査のたびに同じ順位（`docs/todo-summary*.md` の全 176 件規模）を先頭から評価し直すことになる。実際 2026-08-13 の実行は 164 件の候補から **約 50 件をサンプリング**して 0 件と報告しており、毎週同じ古い順位を評価して毎週不採用にする空回りが構造的に起きていた。ここに「判定済み」を積むことで、検査対象は新規登録分へ収束する。 + +**書き手は `/weekly-review` skill**（ユーザー承認後）。facet は read-only なので自分では書けない（ADR-022）。**無人可マークと同様、行の削除や採否そのものは人間の判断**である。 + +**除外の解除（再評価）**: 台帳の採用基準そのものが変わったときは、本表の該当行を削除して再評価対象へ戻す。基準変更は実際に起きている — 2026-07-23 のクロスプラットフォーム対応で、それまで対象外だった cargo-test 検証タスク群が一斉に適格化した（→ [§ 採用タスク (2)](#採用タスク-2-cargo-test-検証タスククロスプラットフォーム対応後2026-07-23)）。**「一度対象外にしたら永久に見ない」ではない**点が watermark 方式との違いで、基準を触った回に本表を棚卸しすること。 + +| 検査日 | 順位 | 対象外の理由 | +|---|---|---| +| — | — | （初回の検査時に記入する。初回は台帳既載を除く全順位が対象） | + ## ライフサイクル ### 2026-08-06 の改訂: ephemeral artifact → 定期更新台帳 @@ -193,7 +207,13 @@ 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 件だが再追加を許しているため、両方の経路を見ないと候補を取りこぼす +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 件でもある場合は必ず明示する。** 「候補なし」と報告してよいのは、上記の全件判定を実際に行ったときだけである 3. **無人可マークの見直し** — [§自律実行可否の 2 段階分類](#自律実行可否の-2-段階分類)の 3 条件を再確認する。特に条件 3（重複の恐れ）は台帳の外にある未マージブランチ・進行中 PR を見ないと判定できないため、この棚卸しでしか確認できない 1〜3 の実行と採否は**人間が決める**（ADR-022）。facet は read-only で findings を上げるだけで、本ファイルを編集しない。