refactor(pre-push): ADR-047 却下で refute facet を撤去 + R4 判定記録 (ADR-056 延長)

.takt/facets/instructions/fix.md

@@ -35,15 +35,6 @@ A deterministic Rust gate (scope guard, ADR-054 layer 3) re-checks the actual fi
 - Use the latest review reports in the Report Directory as primary evidence.
 - Past iteration reports are saved as `{filename}.{timestamp}` in the same directory. For each report, run Glob with a `{report-name}.*` pattern, read up to 2 files in descending timestamp order, and understand persists / reopened trends before starting fixes.
 
-### Optional: refutation-report.md filter (applies whenever refutation-report.md is present)
-
-If the Report Directory contains `refutation-report.md`, a verify (refute) step has already adversarially filtered the reviewer findings. In that case:
-
-- Treat the **Survived Findings** table as your work list. Each row is self-contained (`finding_id`, location, issue, and the carried-over fix suggestion), so fix directly from it. Use the `finding_id` to cross-reference the original reviewer report (`simplicity-review.md` / `security-review.md`) when you need more context on a surviving finding.
-- Fix **only** the findings in the Survived Findings table. Do NOT fix findings listed under **Rejected Findings** -- they were refuted as false positives (a wrongly-rejected one is recaught by the post-pr CodeRabbit layer).
-
-If `refutation-report.md` is absent (post-pr-review, or refute disabled), use all reviewer / analysis reports as usual.
-
 ## Completion criteria (all must be satisfied)
 
 - All findings in this iteration (new / reopened) have been fixed in the correct source tree (not in any read-only zone).

.takt/facets/instructions/supervise.md

@@ -7,10 +7,6 @@ You are the supervisor. The review-fix cycle has either completed or been escala
 3. Check that fixes did not introduce new issues
 4. Verify read-only zone compliance (no writes to .takt/, docs/adr/, templates/, .claude/hooks-config.toml)
 
-## Optional: refutation-report.md (applies whenever refutation-report.md is present)
-
-If the Report Directory contains `refutation-report.md` with Verdict `ALL_REFUTED` and there is no fix report, the verify (refute) step rejected every reviewer finding as a false positive, so there is intentionally no code change. Confirm the rejection reasons are sound (each should cite concrete code-level evidence). If they are, this is **ready to push** -- any wrongly-rejected finding is recaught by the post-pr CodeRabbit layer. If a rejection reason looks unsound, treat it as **issues detected**.
-
 ## Decision criteria
 
 Judge **only the current iteration's** reports -- the latest `review-report` / `fix-report` in the Report Directory (the plain `{filename}` without a `.{timestamp}` suffix). Findings already resolved in earlier iterations, and their archived `{filename}.{timestamp}` reports, are out of scope for this decision.

.takt/facets/policies/review-anomaly.md

@@ -1,8 +1,8 @@
-<!-- Used by: pre-push-review / pre-push-review-refute (all review steps). Shadows the takt builtin `review` policy for pre-push only. See ADR-056. -->
+<!-- Used by: pre-push-review (all review steps). Shadows the takt builtin `review` policy for pre-push only. See ADR-056. The refute variant (ADR-047) was retired 2026-07-19. -->
 
 # Review Policy (anomaly mode)
 
-Shared judgment criteria for the pre-push review steps (reviewers / refutation /
+Shared judgment criteria for the pre-push review steps (reviewers /
 supervisor). This policy deliberately defines **no REJECT checklist of its own**.
 What counts as a blocking problem is owned by each step's instruction facet; this
 policy only constrains **how** a finding must be evidenced, scoped, and tracked.
@@ -27,7 +27,6 @@ Each step's instruction facet defines what qualifies as blocking:
 
 - `review-simplicity` — an articulable anomaly (unexplained complexity, hidden coupling, dead-on-arrival code, ...)
 - `review-security` — a concrete exploit path (who controls the input, what newly becomes possible)
-- `refute-finding` — a finding that survives adversarial refutation
 - `supervise` — the current iteration's blocking findings are resolved
 
 This policy adds none of its own. In particular there is **no list of "REJECT

.takt/workflows/pre-push-review.yaml

@@ -26,7 +26,7 @@ loop_monitors:
       persona: supervisor
       # haiku: judge は Healthy/Unproductive の 2 択 routing のみ (R2 / T13 項目 3)。
       # post-pr-review.yaml の analyze (haiku で approved/needs_fix/user_decision を分類) に前例。
-      # ⚠ 変更時は refute 側 (pre-push-review-refute.yaml) と必ず揃えること (原則 6 / T10 の罠)。
+      # (refute 側 yaml との同期義務は ADR-047 却下 = refute.yaml 削除 (2026-07-19) に伴い解消。)
       model: haiku
       instruction: loop-monitor-reviewers-fix
       rules: