Skip to content

docs(lane-model): 夜間 todo ループの担当管理を lane モデルへ移行する (WP lane-model PR-1) #409

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
aloekun merged 1 commit into from
Aug 16, 2026
Merged

docs(lane-model): 夜間 todo ループの担当管理を lane モデルへ移行する (WP lane-model PR-1) #409

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 12 additions & 18 deletions .takt/facets/instructions/review-todo-whole.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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`.
Expand All @@ -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).
Loading
Loading