mystery-readers

name	mystery-readers
description	推理SF小説ハーネスのフェーズ5。完成した novel.md を「探偵がロジックを解説する直前」まで切り出し、最低10人(推奨12人)の並列読者エージェントに独立して読ませ、探偵の解説前に犯人を当てられるかを検証する。読者には真相(case.json/characters.json)も解決編も渡さない。正答率(solve_rate)・推測分布・拾われた/見落とされた手掛かり・フェアネス判定を readers/aggregate.json に集約する。novel.md に読者への挑戦マーカーがある前提。

mystery-readers — 読者検証(フェーズ5)

完成原稿を「読者への挑戦」直前で切り出し、最低10人の並列読者エージェントに読ませて、 探偵の解説前に犯人へ到達できるかを検証する。フェアプレイの実証テスト。

入力

• ~/mystery-novels/<slug>/novel.md（<!-- CHALLENGE-TO-THE-READER --> マーカー必須）
• 採点用に case.json / characters.json（スキルのみが読む。読者には渡さない）

事前に必ず読むもの

• ~/.claude/skills/mystery-readers/references/reader-protocol.md（切り出し・ペルソナ・採点・集計）
• ~/.claude/skills/mystery-novel/references/data-contract.md（ネタバレ境界）

プロトコル

1. 本文の切り出し。reader-protocol.md の awk コマンドで、挑戦マーカー直前までを ~/mystery-novels/<slug>/readers/_challenge_cut.md に出力。マーカーが無ければ 検証不能としてエラー報告（執筆ステップで設置が必要）。切り出し本文に解決編が 混入していないことを確認。

2. 真の答えを取得（スキル内部のみ）。case.json の perpetrator_id を characters.json で 本名に解決し、真犯人名・手段・動機を採点用に保持。この情報を読者プロンプトに含めない。

3. 読者エージェントを並列起動（最低10、推奨12）。1メッセージで Agent を同時発行。

   • reader-protocol.md のペルソナを割り当て、多様性を確保。
   • 最低1名は subagent_type: "codex-reviewer"（クロスモデル読者。CLAUDE.md原則4）。
   • 各プロンプトに必ず明記:
     • 「readers/_challenge_cut.md だけを読め。プロジェクト内の他ファイル(case.json, characters.json, novel.md 等)を絶対に開くな。」
     • 「あなたは探偵の解説を読む前の読者。犯人・手段・動機を推理し、出力スキーマのJSONで返せ。」
   • 各読者は独立。互いの回答を見せない。

4. 採点（スキル側）。各読者の guessed_culprit を真犯人名と照合（表記ゆれ正規化）。 method/motive の概ね一致も判定。各読者結果を readers/<reader_id>.json に保存。 causal_loop 作品のみ: reader-protocol.md の rubric（bootstrap artifact 特定/閉包の把握/ 事件における役割、の3点中2点以上）で loop_seen を判定（読者スキーマは不変。採点側の 追加集計であり、読者への指示は変えない）。

5. 集計。readers/aggregate.json を reader-protocol.md のスキーマで作成: solve_rate・method_hit_rate・motive_hit_rate・guess_distribution・ clues_readers_found / clues_readers_missed・fairness_signal・notes。 fairness_signal は trick_complexity(tier)依存で判定する。meta.json の settings.trick_complexity（または case.json の trick.complexity_tier、無ければ tier3）を 読み、reader-protocol.md の tier 別目標帯と観測 solve_rate を照合して good / too_easy / unfair_or_too_hard を決める。tier と target_band も aggregate に記録。 難度proxyも集計（LLM読者はsolve_rate飽和するため）: suspicion_spread（1人あたりseriously_suspected 平均数。1に近い＝曖昧さ不足）、misled_rate（misled_by が非空の読者率。低い＝偽の解決が不発）、 meta_guess_rate（reasoning_type=meta_guess の率。高い＝勘で当てられている）、lie_detected_rate （suspected_lies 非空率。低い＝A9違反の疑い）。solve_rate が高くてもこれらが悪ければ「難度不足」と診断。 causal_loop 作品のみ loop_seen_rate も集計する（loop 看破＝how軸が高くても who が 割れていれば健全。loop_seen_rate 単独で too_easy と診断しない）。

6. meta.json 更新。phases.readers.status="done"、phases.readers.solve_rate を記録。

7. 報告。solve_rate と fairness_signal、適用した tier と目標帯、推測分布（真犯人 vs レッドヘリング/偽の解決）、見落とされた重要手掛かり、フェアネス所見を提示。

完了条件

• 読者エージェントを10名以上（codex 読者を含む）起動・採点済み。
• readers/aggregate.json 生成、meta.json に solve_rate 反映。

フェアネス所見の活用（→難易度修復へ還流）

• 読者検証は診断で終わらせず、too_easy を設計修復へ還流する。判定は方向を区別し、 LLM読者の正答率飽和を考慮する（reader-protocol.md「難易度修復のトリガ」）:
  • too_easy（真犯人が首位 かつ Wilson 下限が帯上限超 かつ 難度proxy が退化＝spread<1.5 or misled<0.25 or meta_guess>0.4、または who 一点集中）→ 設計レベルで A10 機会独占／A11 物証集中／ A12 動機独占／A13 過剰決定の解消・B 断片化の修復（workflows/mystery-batch.mjs の難易度ループ）。
  • llm_saturated（solve 高いが proxy 全て健全）→ LLM超読者の飽和とみなし難易度UPしない。 人手/より難しい読者での確認に委ねる。
  • too_hard/unfair（solve が帯下限未満・真犯人に票が入らない）→ 難易度UPはせず、手掛かり 補強／フェアネス見直し。
  • in_band → 修復不要。
• 難易度UP修復はフェアネス退行禁止（load-bearing 手掛かりを削除・曖昧化して難しくするのは 反則）。修復後は再監査で fairplay_clues/knox の pass 維持を確認、崩れたら巻き戻す。
• 単体実行時はユーザーへ所見（方向つき）を提示する。