Knowledge Harness Decisions#

この文書は、知識ハーネスで採用した判断と理由を追記形式で記録する。過去の判断は削除や上書きをせず、変更時は新しい決定を追加して置き換え関係を示す。

D-001: Issue #2をPhase 0の継続状態の正本とする#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: GitHub Issue #2を、Phase 0における公開可能な継続状態の正本とする

  • 理由: ChatGPT、VS Code、GitHub上のAgentが同じ場所から中断・再開できるようにするため

  • 制約: 私的情報、会社情報、非公開会話は記録しない

  • 代替案: 会話履歴やセッション要約を正本にする

  • 不採用理由: 実行環境をまたいだ再開可能性と公開可能性を保証できないため

D-002: 一度のセッションで扱う「次の一手」を一件に限定する#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: STATUSとIssue本文に記載する「次の一手」は常に一件だけにする

  • 理由: 作業範囲の膨張と、未承認フェーズへの移行を防ぐため

  • 代替案: 複数の作業候補を並行して記載する

  • 不採用理由: 再開時に優先順位と完了判定が曖昧になるため

D-003: 継続基盤を4文書に分離する#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: CHARTER.mdDECISIONS.mdSTATUS.mdOPERATIONS.mdを置く

  • 理由: 目的、決定履歴、現在状態、運用手順では責務と更新頻度が異なるため

  • 代替案: 単一文書へ統合する、またはSTATUSとOPERATIONSを統合する

  • 不採用理由: 現在状態の頻繁な更新が、低頻度の方針や追記型の履歴と混在するため

D-004: 記事を公開しない正常終了を認める#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: 意味のある変化がなければ、記事を公開しないことを正常終了とする

  • 理由: 公開頻度ではなく、根拠と読者価値を優先するため

  • 代替案: 毎週の記事公開を成功条件にする

  • 不採用理由: 新規性や根拠の弱い記事を生成する圧力になるため

D-005: PR #3のマージをもってPhase 0を完了する#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: 人間がPR #3をレビューしてマージした時点で、Phase 0の完了条件を満たしたものとする

  • 理由: 継続基盤の4文書、HANDOFF形式、共通再開プロンプトがリポジトリのmainへ反映されたため

  • 証跡: GitHub PR #3

  • 制約: Phase 1の目的、範囲、完了条件は別途人間が決定し、決定前に実装へ着手しない

D-006: Phase 1をOperation設計とする#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: Phase 1では実装より先に、記事候補の受付から公開判断までを小さなOperationと状態遷移へ分解する

  • 理由: 先に処理契約を固定することで、一括AI生成と場当たり的な人間確認を避けるため

  • 代替案: Issue受付、根拠パケット生成、記事生成のいずれかを先に実装する

  • 不採用理由: 境界と停止条件がないまま個別機能を実装すると、手作業とAI判断が再び混在するため

D-007: 人間への質問より安全な自動終了を優先する#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: 通常処理で不確実性、根拠不足、新規性不足が解消できない場合、人間へ質問せずNO_CANDIDATEまたはHOLDで終了する

  • 理由: 人間の判断回数を減らし、公開しないことを正常な結果として扱うため

  • 例外: 公開可能性、恒久方針の変更、最終公開承認は人間が判断する

  • 制約: 安全な終了を、失敗や公開承認として扱わない

D-008: パイプライン設計を専用文書へ分離する#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: 記事処理の状態遷移とOperation契約をPIPELINE.mdに記録する

  • 理由: セッション継続手順を扱うOPERATIONS.mdと、記事処理の実行設計では責務が異なるため

  • 代替案: OPERATIONS.mdへ統合する

  • 不採用理由: 実行パイプラインの変更が、中断・再開プロトコルへ影響しているように見えるため

D-009: 最初の実装対象をO-13 Record Outcomeとする#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: Phase 1完了後の最初の実装対象をO-13 Record Outcomeとする

  • 理由: 他のOperationより先に、成功、非公開終了、失敗、再開条件を同じ形式で残せるようにするため

  • 実装範囲: 共通契約の検証、run_id単位の冪等な保存、日本語HANDOFF、人間判断を含むMetrics集計

  • 制約: 集計結果から恒久方針を自動採用せず、変更候補として人間へ提示する

D-010: O-13の次にO-01 Capture Requestを実装する#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: 二番目の実装対象を、パイプライン入口のO-01 Capture Requestとする

  • 理由: 公開可能な入力を共通契約へ正規化し、後続Operationが会話履歴や入力元の形式へ依存しないようにするため

  • 実装範囲: 公開Issue、公開承認済み入力、公開可否未確認入力の受付、run_id単位の冪等な保存

  • 制約: Issue作成だけでO-02以降を開始せず、公開可否未確認時だけ人間へ確認を残す

D-011: O-01の次にO-02 Authorize Runを実装する#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: 三番目の実装対象をO-02 Authorize Runとする

  • 理由: O-01で保存したRequestと、人間が事前に与える実行トリガーを分離し、Issue作成だけで処理が始まらない境界を実装するため

  • 実装範囲: 明示ラベルの有無による許可判定、run_id単位の冪等な保存、待機記録

  • 制約: 既定ラベルはknowledge-harness:runとするがCLIで変更可能にし、ラベルがない場合は質問や催促を行わない

D-012: O-02の次にO-03 Screen Safetyを実装する#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: 四番目の実装対象をO-03 Screen Safetyとする

  • 理由: 許可済みRequestを外部取得へ渡す前に、秘密情報、個人情報、明確な非公開情報を決定的な規則で除外するため

  • 実装範囲: 秘密情報と非公開マーカーの拒否、メールと電話番号のマスク、自動判定不能入力の保留、冪等な保存

  • 制約: 拒否・保留した入力本文を成果物へ複製せず、自動判定不能な場合だけ公開可能性を人間へ確認する

D-013: O-03の次にO-04 Collect Evidenceを実装する#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: 五番目の実装対象をO-04 Collect Evidenceとし、公式・一次情報を優先しながら一般Web上の説明と評価も区別して収集する

  • 理由: 後続のAIが、取得できた事実だけでなく、取得不能、根拠不足、対象範囲の曖昧さ、矛盾を検証できるEvidence Setを必要とするため

  • 実装範囲: 公開情報源の分類、上限付き収集、重複排除、限定的な再試行、必須メタデータと不確実性の冪等な保存、Metrics記録

  • 初期上限: 検索3ラウンド、各4クエリ、本文取得20件、採用12件、同一ドメイン3件、処理時間15分、一時的失敗の追加再試行2回

  • 判断境界: 何らかの証拠が得られた場合は不足や矛盾を隠さず後続へ渡し、根拠充足性と記事候補の採否はO-05とO-06へ委ねる

  • 改善方法: 原則10実行分のO-04 Metricsと後続で判明した根拠不足から上限値の変更候補を作る

  • 制約: 多数意見を事実の正しさと扱わず、上限値や恒久方針を自動変更しない

D-014: O-04の次にO-05 Build Evidence Packetを実装する#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: 六番目の実装対象をO-05 Build Evidence Packetとし、Evidence Setを事実、推測、未確認事項、世間的反応、矛盾へ分離して整理する

  • 理由: O-06のAI Judgeが、主張と不確実性を出典まで追跡し、根拠充足性と記事候補の採否をEvidence Setの形式へ依存せず評価できるようにするため

  • 実装範囲: O-04契約検証、論点別整理、source_idによる出典追跡、過去記事との差分候補、不確実性の継承、冪等な保存

  • 判断境界: O-05は材料を構造化するが、根拠充足性、新規性、読者価値、新しく記事にする理由の成立可否を決定しない

  • 制約: 新しい取得、根拠のない補完、矛盾の黙示的な解消、記事構成と本文生成を行わない

D-015: O-05の次にO-06 Judge Candidateを実装する#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: 七番目の実装対象をO-06 Judge Candidateとし、5評価軸を独立に判定するAI Judgeとして実装する

  • 理由: 記事候補の採否を材料整理から分離し、公開本数ではなく根拠、新規性、読者価値、著者固有の問い、不確実性に基づいて安全に終了または続行するため

  • 評価軸: 根拠充足性、新規性、外部読者が再利用できる価値、著者固有の問いまたは判断、不確実性の影響

  • 決定規則: 必須軸のFAILNO_CANDIDATEFAILなしのUNCERTAINまたは高影響の不確実性はHOLD、全必須軸が確信度0.70以上のPASSならCANDIDATE_ACCEPTED

  • 判断境界: O-06は記事候補の採否までを担当し、記事の中心メッセージ、対象読者、構成、本文を決めない

  • 制約: 人間へ根拠不足の穴埋めを求めず、記事数を増やすために閾値を下げず、評価基準を自動変更しない

D-016: O-06の次にO-07 Plan Articleを実装する#

  • 日付: 2026-08-11

  • 状態: 採用

  • 決定: 八番目の実装対象をO-07 Plan Articleとし、Accepted Candidateを出典追跡可能なArticle Planへ変換するSkill / Agentと決定的な検証Programとして実装する

  • 理由: 本文生成前に中心メッセージ、読者、検索動機、構成、除外事項、不確実性の扱いを固定し、O-08による意味や事実の追加を防ぐため

  • 成果物: 仮題、中心メッセージ一文、対象読者、検索動機、構成型、節ごとの目的・読者価値・Packet参照、除外事項、不確実性の扱い

  • 構成型: TUTORIALCONCEPT_EXPLANATIONCHANGE_ANALYSISTROUBLESHOOTINGDECISION_RECORD

  • 質問境界: 著者固有の動機が中心メッセージに不可欠で復元不能な場合だけ、一回、最大3問の公開可能な質問でHOLDする

  • 判断境界: O-07はArticle Planまでを担当し、本文、reStructuredText、英訳、画像、最終タイトル、公開日を生成・確定しない

  • 制約: 新しい調査、候補採否の再判定、技術的事実や根拠不足の人間による穴埋めを行わない