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.md、DECISIONS.md、STATUS.md、OPERATIONS.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-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と後続で判明した根拠不足から上限値の変更候補を作る
制約: 多数意見を事実の正しさと扱わず、上限値や恒久方針を自動変更しない