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と後続で判明した根拠不足から上限値の変更候補を作る
制約: 多数意見を事実の正しさと扱わず、上限値や恒久方針を自動変更しない
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として実装する理由: 記事候補の採否を材料整理から分離し、公開本数ではなく根拠、新規性、読者価値、著者固有の問い、不確実性に基づいて安全に終了または続行するため
評価軸: 根拠充足性、新規性、外部読者が再利用できる価値、著者固有の問いまたは判断、不確実性の影響
決定規則: 必須軸の
FAILはNO_CANDIDATE、FAILなしの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参照、除外事項、不確実性の扱い
構成型:
TUTORIAL、CONCEPT_EXPLANATION、CHANGE_ANALYSIS、TROUBLESHOOTING、DECISION_RECORD質問境界: 著者固有の動機が中心メッセージに不可欠で復元不能な場合だけ、一回、最大3問の公開可能な質問で
HOLDする判断境界: O-07はArticle Planまでを担当し、本文、reStructuredText、英訳、画像、最終タイトル、公開日を生成・確定しない
制約: 新しい調査、候補採否の再判定、技術的事実や根拠不足の人間による穴埋めを行わない
D-017: O-07の次にO-08 Draft Articleを実装する#
日付: 2026-08-11
状態: 採用
決定: 九番目の実装対象をO-08
Draft Articleとし、節別本文案を検証して日本語reStructuredTextと追跡manifestを生成するSkill / AgentとProgramとして実装する理由: 自由形式の本文を直接公開用ディレクトリへ置かず、Article Planの節、Packet参照、不確実性の扱いを機械検証できる中間成果物にするため
入力案: Plan節ごとの一意な本文ブロックID、reStructuredText本文、Packet参照
成果物:
_notes/knowledge_harness/drafts/<run_id>/draft.rstとdraft_manifest.json安全境界: 外部内容を取り込むdirectiveを拒否し、Plan外参照、未計画の節、除外対象の不確実性参照を許可しない
判断境界: O-08は検証前Draftまでを担当し、事実性、意味の飛躍、読者価値、構成品質、リンク、ビルド、秘密情報の判定をO-09へ残す
公開境界: 公開用
postdirective、最終タイトル、公開日、docs/blog/posts/への配置、Draft PRを生成しない制約: 新しい調査、上流成果物の変更、英訳、画像生成、人間への質問を行わない
D-018: O-08の次にO-09 Validate Draftを実装する#
日付: 2026-08-11
状態: 採用
決定: 十番目の実装対象をO-09
Validate Draftとし、決定的なProgram検査と5軸のAI Judge評価を統合するValidation Operationとして実装する理由: 公開準備前に機械検査と意味評価を独立して記録し、品質不足を人間による根拠補完ではなく安全な保留として扱うため
Program検査: manifest整合性、reStructuredText構文、メタデータ、リンク許可範囲、既存記事重複、秘密情報・個人情報
AI評価軸: 事実的根拠、意味の飛躍、外部読者価値、Article Plan整合、不確実性の扱い
自動修正: 末尾空白、最終改行、Program生成見出しの装飾長だけを一回修正し、本文の意味・事実・主張・構成を変更しない
決定規則: Programエラーなし、全必須軸が確信度0.70以上の
PASSの場合だけVALIDATED / ADVANCEとし、それ以外はHOLD / HOLDとする重複境界: 正規化タイトル一致はエラー、本文類似度0.85以上は重複候補としてAI Judgeへ渡す
方針境界: 現行方針では判定不能な恒久問題だけを選択肢と影響付きの候補として記録し、単発修正を方針質問にしない
制約: 新しい調査、内容の自動書き換え、公開用配置、英訳、画像生成、Draft PR作成を行わない
D-019: O-09の次にO-10 Prepare Reviewを実装する#
日付: 2026-08-11
状態: 採用
決定: 十一番目の実装対象をO-10
Prepare Reviewとし、検証済みDraftを日本語のReview PacketとDraft PRへ変換するSkill / AgentとProgramとして実装する理由: 人間が機械用の英語コードを解読せず、根拠、不確実性、検証結果、選択肢、無回答時の扱いを理解して最終公開判断できるようにするため
公開候補: 最終タイトル、安全なslug、Asia/Tokyo基準で最初の未使用未来日、ablog metadataを検証し、
docs/blog/posts/YYYY-MM-DD-slug.rstへ配置するReview Packet: 中心メッセージ、主要根拠、不確実性、検証結果、AIと人間の担当範囲、変更ファイル、判断の4選択肢を日本語で保存する
判断境界: O-10は
REVIEW_READY / ADVANCEまでを担当し、merge、修正要求、棄却、恒久方針候補の判断をO-11へ残す冪等性: 一実行につき一つのbranchとDraft PRだけを準備し、同一入力の再実行で公開候補やPRを重複生成しない
制約: O-09未検証の本文変更、新しい調査、英訳、画像、既存記事変更、公開承認を行わない
D-020: O-10の次にO-11 Decide Publicationを実装する#
日付: 2026-08-11
状態: 採用
決定: 十二番目の実装対象をO-11
Decide Publicationとし、日本語の人間判断を監査可能なPublication Decisionへ変換するProgramとして実装する理由: 最終公開権限を人間に限定しつつ、英語コードや自由文の推測による誤公開を防ぎ、判断者・対象・理由・GitHub上の根拠を追跡するため
選択肢: 「公開を承認する」「今回だけ修正を求める」「公開しない」「今後の方針として検討する」の4つを日本語表示する
承認境界: 対象PRのmerge事実だけを
APPROVED / ADVANCEとし、コメント上の賛成表現だけでは公開承認しない修正境界: 具体的な日本語指示、対象箇所、GitHub参照を持つ今回限りの修正だけを
REVISION / ADVANCEとしてO-12へ渡す安全境界: 棄却、方針候補、無回答、曖昧・矛盾、actor・PR・SHA不整合は公開せず
HOLD / HOLDとする制約: GitHub操作、修正反映、恒久方針採用、英訳、画像、公開後確認を行わない
D-021: O-11の次にO-12 Apply Feedbackを実装する#
日付: 2026-08-11
状態: 採用
決定: 十三番目の実装対象をO-12
Apply Feedbackとし、今回限りの具体的修正だけを反映してO-09へ戻すSkill / AgentとProgramとして実装する理由: 人間の修正要求を未依頼の全面改稿へ広げず、修正前後と根拠を追跡しながら再検証・再レビューできるようにするため
入力境界: O-11の
REVISION / ADVANCE、具体的な日本語指示、対象箇所、GitHub参照、対象commit、対応するDraft成果物を必須とする変更境界: 指定対象だけを変更し、未指定ブロック、中心メッセージ、Article Planの節構成、新しい根拠を変更・追加しない
回数境界: AI修正は同一記事2回までとし、3回目を実行せず
HOLD / HOLDにする再検証境界: 正常時は
REVISED / ADVANCEとしてO-09へ戻し、O-10とO-11も再実行する安全境界: 対象不明、根拠追加が必要、上流変更が必要、指示外変更がある場合は推測せず
HOLD / HOLDにする制約: 新しい調査、上流成果物変更、公開候補への再配置、GitHub操作、公開承認、恒久方針採用、英訳、画像を行わない