Knowledge Harness Operations#

状態の正本#

Phase 0ではGitHub Issue #2を公開可能な継続状態の正本とする
STATUS.mdはリポジトリ内の状態スナップショットとする
会話履歴やセッション要約を作業状態の正本にしない
作業開始時はIssue本文、最新HANDOFF、STATUS.mdの順に確認し、矛盾があれば作業を止める

作業開始#

着手前に次の三点を日本語で要約する。

今回行う一件
変更対象
停止条件

一度のセッションで扱う「次の一手」は一件だけとし、未承認の次フェーズへ進まない。

状態更新#

完了後、検証結果を記録してから次の一手を一件だけ設定する
STATUS.mdとIssue本文の現在地、次の一手、ブロッカーを一致させる
新しい恒久判断はDECISIONS.mdへ追記する
途中で中断する場合も、未完了状態と再開地点を隠さない
失敗した作業を完了扱いにせず、失敗原因と次の試行点を残す
私的情報、会社情報、非公開会話を公開Issueや公開文書へ記録しない

HANDOFF#

セッション終了時はIssue #2へ次の形式のコメントを一件追加する。

## HANDOFF YYYY-MM-DD

### 完了
- ...

### 決定
- ...

### 検証
- ...

### 未完了
- ...

### 次の一手
- 一件だけ記載する

### ブロッカー
- なし / ...

### 関連
- Issue / PR / branch / commit / file

再開プロンプト#

ChatGPT / Codex Work#

mtakagishi/note のIssue #2を継続状態の正本として読み、最新のHANDOFF、STATUS.md、「次の一手」から作業を再開してください。
着手前に、今回行う一件、変更対象、停止条件を要約してください。
既存の私的な会話履歴を推測・要約して入力に使わないでください。

VS Code#

このリポジトリのIssue #2を継続状態の正本として読み、最新のHANDOFF、STATUS.md、「次の一手」から作業を再開してください。
今回の作業は一件に限定し、完了時にSTATUSとHANDOFFを更新してください。
未承認の次フェーズへ進まないでください。

不一致や判断待ち#

Issue、最新HANDOFF、STATUS.mdに不一致がある場合は変更を始めない
新しい判断が必要な場合は、選択肢と影響を示して人間の判断を待つ
人間が応答しない場合は公開せず保留し、許可された他の処理だけを継続する

記事処理パイプラインとの境界#

この文書は、作業セッションの中断、再開、状態同期だけを扱う
記事候補の受付から公開判断までの状態遷移とOperation契約はPIPELINE.mdを正とする
パイプライン実行中の状態は成果物として保存し、会話履歴だけに保持しない

O-13 Record Outcomeの実行#

O-13はパイプラインの終了または引き継ぎ時に、状態、理由、成果物、検証結果、次の一手を保存する。次のように実行する。

rye run python -m note.knowledge_harness.outcomes `
  --run-id run-20260811-001 `
  --state-before VALIDATED `
  --state-after REVIEW_READY `
  --result ADVANCE `
  --reason-code DRAFT_PR_READY `
  --summary-ja "Draft PRを作成し、公開判断を待てる状態になりました。" `
  --producer program `
  --input-ref issue:2 `
  --artifact-ref pr:6 `
  --verification-ref unittest:pass `
  --next-action "人間がDraft PRを確認する" `
  --human-action publication

既定では_notes/knowledge_harness/outcomes/<run_id>/にoutcome.jsonとHANDOFF.mdを保存し、_notes/knowledge_harness/outcomes/metrics.jsonを再集計する。このディレクトリは実行時成果物のためGit管理しない。

同じrun_idの再実行では記録を重複させず、内容が変わった場合だけ更新する
--created-atを省略した再実行では既存の記録時刻を維持する
--human-actionはnone、publication、policy、privacy、exceptionから選ぶ
Metricsは反復する人間判断を見つける材料とし、DECISIONS.mdを自動更新しない

検証には次を使う。

rye run python -m unittest discover -s tests -p "test_*.py"
rye run ruff check src/note/knowledge_harness tests/test_record_outcome.py

O-01 Capture Requestの実行#

O-01は公開可能な「知りたいこと」を共通形式のRequestへ変換する。公開Issueは公開可能と扱い、許可済みの別入力はapproved_inputを指定する。

rye run python -m note.knowledge_harness.capture_request `
  --run-id run-20260811-002 `
  --question-ja "公開Issueから記事候補を安全に受け付けるには？" `
  --source-ref issue:7 `
  --source-kind public_issue

既定では_notes/knowledge_harness/requests/<run_id>/request.jsonへ保存する。

public_issueとapproved_inputはCAPTURED / ADVANCEとする
unconfirmed_inputはHOLDとし、公開可能性だけを人間へ確認する
問いが空の場合は、記事内容を推測せず入力エラーとする
同じrun_idの再実行では重複させず、内容が変わった場合だけ更新する
O-01はO-02以降を自動実行しない

O-02 Authorize Runの実行#

O-02はO-01が生成したRequestと現在のラベル一覧を受け取り、明示的な実行ラベルがある場合だけ後続処理を許可する。

rye run python -m note.knowledge_harness.authorize_run `
  --request-file _notes/knowledge_harness/requests/run-20260811-002/request.json `
  --label knowledge-harness:run

既定では_notes/knowledge_harness/authorized/<run_id>/authorization.jsonへ保存する。

既定の実行ラベルはknowledge-harness:runとする
別のラベルを使う場合は--required-labelで変更できる
必須ラベルがあればAUTHORIZED / ADVANCEとする
必須ラベルがなければCAPTURED / HOLDとし、状態を進めない
ラベルがない場合は人間へ質問や催促を行わない
O-01がHOLDにしたRequestはラベルがあっても許可しない
同じrun_idへラベルを追加して再実行した場合は、既存記録を更新する

O-03 Screen Safetyの実行#

O-03は許可済みRequestを決定的な規則で検査し、安全な情報だけを後続へ渡す。

rye run python -m note.knowledge_harness.screen_safety `
  --authorization-file _notes/knowledge_harness/authorized/run-20260811-002/authorization.json

既定では_notes/knowledge_harness/screened/<run_id>/screening.jsonへ保存する。

秘密鍵、代表的なアクセストークン、秘密値の代入を検出した場合はREJECTEDとする
社外秘、部外秘、非公開会話などの明確な非公開マーカーを検出した場合はREJECTEDとする
固有の非公開語は--restricted-termで追加できる
メールアドレスと電話番号はマスクし、マスク後のRequestだけをSCREENEDとして渡す
拒否した入力本文は成果物へ複製しない
自動判定不能と分かっている場合は--assessment uncertainで本文を保持せずHOLDとし、公開可能性だけを確認する
明確に非公開と分かっている場合は--assessment privateで質問せずREJECTEDとする
O-02が待機中のAuthorizationは検査しない

O-04 Collect Evidenceの実行#

O-04はO-03を通過したRequestと、検索で発見した公開情報源候補を受け取り、本文を取得してEvidence Setを作る。外部検索サービスとの本格連携はPhase 6のスコープ外であるため、検索結果はJSONマニフェストとして渡す。

rye run python -m note.knowledge_harness.collect_evidence `
  --screening-file _notes/knowledge_harness/screened/run-20260811-002/screening.json `
  --sources-file sources.json

sources.jsonは次の形式にする。

{
  "sources": [
    {
      "url": "https://example.com/official-document",
      "source_type": "primary",
      "title": "公式文書",
      "publisher": "Example",
      "published_at": "2026-08-11",
      "target_version": "1.0",
      "summary_ja": "確認対象となる公式説明の要約",
      "supports": ["確認できた事実"],
      "limitations": ["この資料だけでは確認できない事項"],
      "confidence": "high",
      "confidence_reason": "公式文書であるため",
      "search_round": 1,
      "query": "example 公式文書",
      "topics": ["対象仕様"],
      "uncertainties": [],
      "contradictions": []
    }
  ]
}

既定では_notes/knowledge_harness/evidence/<run_id>/evidence.jsonへ保存する。

source_typeはprimary、secondary、community、discovery_onlyから選ぶ
URLは公開HTTP(S)だけを受け付け、認証やアクセス制限を回避しない
取得本文そのものは保存せず、SHA-256、バイト数、Content-Typeと提供された該当箇所・要約を保存する
URL断片を除いた同一URLを重複排除し、同一ドメインからの採用は3件までとする
検索3ラウンド、各4クエリ、取得20回、採用12件、15分を初期上限とする
一時的な失敗は追加2回まで再試行し、恒久的失敗とともに理由を保存する
必要範囲を確認できた候補へ"complete_scope": trueを指定すると、取得成功後に早期終了する
1件以上取得できれば、不足や矛盾があってもEVIDENCE_READY / ADVANCEとする
一時的失敗だけならSCREENED / RETRYABLE_ERROR、全面的に取得不能ならHOLDとする
同じ入力と同じ取得内容では成果物を書き換えない

O-04のMetricsをO-13へ集計する場合は、Evidence Set自体をMetrics入力として指定する。

rye run python -m note.knowledge_harness.outcomes `
  --run-id run-20260811-002 `
  --state-before SCREENED `
  --state-after EVIDENCE_READY `
  --result ADVANCE `
  --reason-code EVIDENCE_COLLECTED `
  --summary-ja "公開情報を取得し、不足と矛盾を含むEvidence Setを記録しました。" `
  --producer program `
  --source-operation O-04 `
  --operation-metrics-file _notes/knowledge_harness/evidence/run-20260811-002/evidence.json `
  --artifact-ref _notes/knowledge_harness/evidence/run-20260811-002/evidence.json `
  --next-action "O-05 Build Evidence Packetへ渡す" `
  --human-action none

O-13は数値MetricsをOperation別に合計する。初期上限の変更は自動採用せず、原則10実行分を人間が確認する。

O-05 Build Evidence Packetの実行#

O-05はSkill / AgentがEvidence Setを読んで作った整理案を、Programで出典検証してEvidence Packetへ保存する。意味整理と決定的な検証を分け、AIが存在しない根拠を追加できないようにする。

rye run python -m note.knowledge_harness.build_evidence_packet `
  --evidence-file _notes/knowledge_harness/evidence/run-20260811-002/evidence.json `
  --draft-file packet-draft.json

packet-draft.jsonは次の形式にする。

{
  "summary_ja": "取得済み根拠を論点別に整理しました。",
  "topics": [
    {
      "topic_id": "topic-001",
      "title_ja": "仕様と利用者評価",
      "items": [
        {
          "item_id": "item-001",
          "kind": "fact",
          "statement_ja": "公式仕様に対象機能が記載されています。",
          "source_ids": ["source-001"],
          "notes_ja": "対象バージョンを限定して扱います。"
        },
        {
          "item_id": "item-002",
          "kind": "contradiction",
          "statement_ja": "公式仕様と利用者報告に差があります。",
          "source_ids": ["source-001", "source-003"]
        }
      ]
    }
  ],
  "past_articles": {
    "article_refs": ["blog:2026-example"],
    "known_items": [],
    "difference_candidates": [],
    "recheck_items": []
  }
}

既定では_notes/knowledge_harness/packets/<run_id>/evidence_packet.jsonへ保存する。

kindはfact、inference、unconfirmed、community_reaction、contradictionから選ぶ
すべての記述へEvidence Setに実在するsource_idを一件以上指定する
contradictionには異なる根拠を二件以上指定する
community_reactionにはsecondaryまたはcommunity情報源を一件以上含める
item_idとtopic_idはそれぞれPacket内で一意にする
説明が空、出典が存在しない、分類条件を満たさない整理案は保存しない
過去記事参照がない場合、既知事項と差分候補を作らずUNCONFIRMED_NO_PAST_ARTICLEとする
Evidence Setの取得失敗、不確実性、Metricsを欠落させずPacketへ継承する
同じEvidence Setと整理案の再実行では成果物を書き換えない
O-05は新しい情報取得、矛盾の解消、根拠充足性や記事候補の採否判断を行わない

O-06 Judge Candidateの実行#

O-06はAI JudgeがEvidence Packetを5軸で評価した判定案をProgramで検証し、記事候補の採否をCandidate Decisionへ保存する。

rye run python -m note.knowledge_harness.judge_candidate `
  --packet-file _notes/knowledge_harness/packets/run-20260811-002/evidence_packet.json `
  --judgment-file candidate-judgment.json

candidate-judgment.jsonは次の形式にする。5評価軸すべてに、判定、確信度、理由、Evidence Packet内の参照項目を指定する。

{
  "rubric_version": "candidate-v1",
  "judge_id": "judge-example",
  "evaluations": {
    "evidence_sufficiency": {
      "verdict": "PASS",
      "confidence": 0.9,
      "reason_ja": "中心論点を一次情報が支えています。",
      "packet_refs": ["topics/topic-001/items/item-001"]
    },
    "novelty": {
      "verdict": "PASS",
      "confidence": 0.8,
      "reason_ja": "過去記事との差分候補を確認できます。",
      "packet_refs": ["past_articles/difference_candidates/item-002"]
    },
    "reader_value": {
      "verdict": "PASS",
      "confidence": 0.8,
      "reason_ja": "外部読者が手順を転用できます。",
      "packet_refs": ["summary_ja"]
    },
    "author_specific_question": {
      "verdict": "PASS",
      "confidence": 0.9,
      "reason_ja": "著者の問いをRequestから復元できます。",
      "packet_refs": ["screened_request"]
    },
    "uncertainty_impact": {
      "verdict": "PASS",
      "confidence": 0.8,
      "impact": "MEDIUM",
      "reason_ja": "未確認範囲は中心論点を覆しません。",
      "packet_refs": ["uncertainties/0"]
    }
  }
}

既定では_notes/knowledge_harness/decisions/<run_id>/candidate_decision.jsonへ保存する。

verdictはPASS、FAIL、UNCERTAIN、impactはLOW、MEDIUM、HIGHから選ぶ
Packet参照はtopics/<topic_id>/items/<item_id>など、実在する項目だけを受け付ける
必須4軸のいずれかがFAILならNO_CANDIDATE / NO_CANDIDATEとして正常終了する
必須軸にUNCERTAINがある、または不確実性の影響がHIGHならHOLD / HOLDとする
確信度0.70未満のPASSはProgramがUNCERTAINへ正規化する
過去記事との比較がない場合、新規性のPASSはUNCERTAINへ正規化する
全必須軸が確信度0.70以上のPASSで、不確実性の影響がLOWまたはMEDIUMの場合だけCANDIDATE_ACCEPTED / ADVANCEとする
非採用と保留では人間へ質問せず、根拠不足を補完しない
同じPacketと判定案の再実行では成果物を書き換えない
O-06はO-07以降の記事計画や本文生成を実行しない

O-07 Plan Articleの実行#

O-07はSkill / Agentが作る計画案をProgramで検証し、O-08が新しい事実や意図を追加せず展開できるArticle Planへ保存する。

rye run python -m note.knowledge_harness.plan_article `
  --decision-file _notes/knowledge_harness/decisions/run-20260811-002/candidate_decision.json `
  --packet-file _notes/knowledge_harness/packets/run-20260811-002/evidence_packet.json `
  --draft-file article-plan-draft.json

通常のarticle-plan-draft.jsonは次の形式にする。

{
  "mode": "PLAN",
  "plan_version": "article-plan-v1",
  "planner_id": "planner-example",
  "working_title_ja": "変更を安全に運用する方法",
  "central_message_ja": "根拠と不確実性を分けると変更を安全に運用できます。",
  "target_readers": ["変更を導入する技術者"],
  "search_intents": ["変更の安全な運用方法を知りたい"],
  "structure_pattern": "TUTORIAL",
  "sections": [
    {
      "section_id": "section-001",
      "heading_ja": "変更点を確認する",
      "purpose_ja": "確認すべき差分を示します。",
      "reader_takeaway_ja": "差分を根拠まで追跡できます。",
      "packet_refs": ["topics/topic-001/items/item-001"]
    }
  ],
  "excluded_topics": [
    {
      "topic_ja": "対象外の版",
      "reason_ja": "根拠を確認できないためです。"
    }
  ],
  "uncertainty_treatments": [
    {
      "packet_ref": "uncertainties/0",
      "action": "DISCLOSE",
      "reason_ja": "適用範囲を読者へ明示するためです。"
    }
  ]
}

既定では_notes/knowledge_harness/plans/<run_id>/article_plan.jsonへ保存する。

同じrun_idのCANDIDATE_ACCEPTED / ADVANCEとPACKET_READY / ADVANCEだけを受け付ける
構成型はTUTORIAL、CONCEPT_EXPLANATION、CHANGE_ANALYSIS、TROUBLESHOOTING、DECISION_RECORDから選ぶ
各節に一意なID、見出し、目的、読者が得るもの、実在するPacket参照を指定する
Evidence Packetのすべての不確実性にDISCLOSE、LIMIT_CLAIM、EXCLUDEの扱いと理由を指定する
正常な計画はPLAN_READY / ADVANCEとし、人間へ質問しない
同じ入力の再実行では成果物を書き換えない

著者固有の動機が中心メッセージに不可欠で、Packetから復元できない場合だけmodeをAUTHOR_QUESTIONにする。

{
  "mode": "AUTHOR_QUESTION",
  "plan_version": "article-plan-v1",
  "planner_id": "planner-example",
  "question_reason_ja": "著者固有の動機を中心メッセージに反映するためです。",
  "questions": [
    {
      "question_id": "question-001",
      "question_kind": "AUTHOR_MOTIVATION",
      "question_ja": "この変更を調べたきっかけは何ですか？",
      "purpose_ja": "記事の中心となる著者の動機を確認します。",
      "packet_refs": ["screened_request"]
    }
  ]
}

質問は一回、最大3問、AUTHOR_MOTIVATIONだけに限定し、HOLD / HOLDとする
技術的事実、根拠不足、構成の好みを質問しない
保存後に質問を別内容へ差し替えない
回答後にPLANへ進む場合は、公開可能な回答の参照をauthor_context_refへ指定する
回答がなくても安全な計画を作れる場合は質問せず、不確実性の扱いを指定して進める
O-07は記事本文、reStructuredText、英訳、画像、最終タイトル、公開日を生成・確定しない

O-08 Draft Articleの実行#

O-08はSkill / Agentが作る節別本文案をProgramで検証し、日本語reStructuredTextのDraftとPacket参照manifestへ保存する。

rye run python -m note.knowledge_harness.draft_article `
  --plan-file _notes/knowledge_harness/plans/run-20260811-002/article_plan.json `
  --packet-file _notes/knowledge_harness/packets/run-20260811-002/evidence_packet.json `
  --proposal-file article-draft-proposal.json

article-draft-proposal.jsonは次の形式にする。

{
  "draft_version": "article-draft-v1",
  "drafter_id": "drafter-example",
  "sections": [
    {
      "section_id": "section-001",
      "blocks": [
        {
          "block_id": "block-001",
          "body_rst": "公式情報で確認できる変更点を説明します。",
          "packet_refs": ["topics/topic-001/items/item-001"]
        },
        {
          "block_id": "block-002",
          "body_rst": "対象バージョンの一部は未確認です。",
          "packet_refs": ["uncertainties/0"]
        }
      ]
    }
  ]
}

既定では次の中間成果物を保存する。

_notes/knowledge_harness/drafts/<run_id>/draft.rst
_notes/knowledge_harness/drafts/<run_id>/draft_manifest.json

検証と生成の規則は次のとおり。

同じrun_idのPLAN_READY / ADVANCEとPACKET_READY / ADVANCEだけを受け付ける
Article Planの全節を同じIDと順序で一回ずつ指定する
各節に一件以上の本文ブロックを指定し、block_idはDraft全体で一意にする
本文ブロックのPacket参照は、そのPlan節で許可された参照だけに限定する
各節の計画済み参照を少なくとも一つの本文ブロックへ対応付ける
DISCLOSEとLIMIT_CLAIMの不確実性を本文で使用し、EXCLUDE対象は使用しない
raw、include、literalinclude、image、figure、post directiveを本文ブロックへ含めない
本文ブロック内にPlan外のreStructuredText見出しを追加しない
manifestへ各ブロックの節ID、Packet参照、SHA-256を保存する
Draft冒頭に記事状態、未確定の公開日、情報基準日、対象バージョン、生成動機、AI担当範囲、人間の確認範囲を表示する
Packetに対象バージョンがなければ推測せず未確認とする
公開用post directiveを生成せず、docs/blog/posts/への出力を拒否する
同じ入力の再実行ではdraft.rstとmanifestを書き換えない
O-08は人間へ質問せずDRAFT_READY / ADVANCEとする
事実性、意味の飛躍、読者価値、構成品質、リンク、ビルド、秘密情報はO-09で検証する

O-09 Validate Draftの実行#

O-09はO-08のDraftをProgramとAI Judgeで検証し、修正済みDraftとValidation Reportを中間成果物として保存する。

rye run python -m note.knowledge_harness.validate_draft `
  --draft-file _notes/knowledge_harness/drafts/run-20260811-002/draft.rst `
  --manifest-file _notes/knowledge_harness/drafts/run-20260811-002/draft_manifest.json `
  --plan-file _notes/knowledge_harness/plans/run-20260811-002/article_plan.json `
  --packet-file _notes/knowledge_harness/packets/run-20260811-002/evidence_packet.json `
  --judgment-file draft-validation-judgment.json

draft-validation-judgment.jsonは次の形式にする。5評価軸すべてに判定、確信度、理由、実在するDraftブロックとPacket項目の参照を指定する。

{
  "rubric_version": "draft-validation-v1",
  "judge_id": "judge-example",
  "evaluations": {
    "factual_grounding": {
      "verdict": "PASS",
      "confidence": 0.9,
      "reason_ja": "記述が指定した根拠の範囲内です。",
      "block_ids": ["block-001"],
      "packet_refs": ["topics/topic-001/items/item-001"]
    },
    "semantic_leap": {
      "verdict": "PASS",
      "confidence": 0.9,
      "reason_ja": "根拠から結論への飛躍はありません。",
      "block_ids": ["block-001"],
      "packet_refs": ["topics/topic-001/items/item-001"]
    },
    "reader_value": {
      "verdict": "PASS",
      "confidence": 0.8,
      "reason_ja": "計画した読者価値を本文で伝えています。",
      "block_ids": ["block-001"],
      "packet_refs": ["topics/topic-001/items/item-001"]
    },
    "plan_alignment": {
      "verdict": "PASS",
      "confidence": 0.9,
      "reason_ja": "Article Planに沿っています。",
      "block_ids": ["block-001"],
      "packet_refs": ["topics/topic-001/items/item-001"]
    },
    "uncertainty_handling": {
      "verdict": "PASS",
      "confidence": 0.8,
      "reason_ja": "未確認事項を明示しています。",
      "block_ids": ["block-002"],
      "packet_refs": ["uncertainties/0"]
    }
  },
  "policy_change_candidate": {"required": false}
}

既定では次の中間成果物を保存する。

_notes/knowledge_harness/validations/<run_id>/validated_draft.rst
_notes/knowledge_harness/validations/<run_id>/validation_report.json

検証と判定の規則は次のとおり。

同じrun_idのDRAFT_READY / ADVANCE、Article Plan、Evidence Packetだけを受け付ける
元DraftとmanifestのSHA-256、節順、ブロック本文・SHA-256・Packet参照の整合性を検査する
reStructuredText構文、必須metadata、外部・ローカルリンク、秘密情報、個人情報、非公開マーカーを検査する
外部URLはEvidence Packetのsource_catalogに記録されたURLだけを許可する
既存記事との正規化タイトル一致はError、正規化本文の類似度0.85以上はWarning候補とする
末尾空白、最終改行、生成された見出し装飾長だけを一回自動修正し、O-08の入力Draftは変更しない
AI Judgeの判定はPASS、FAIL、UNCERTAINとし、確信度0.70未満のPASSはUNCERTAINへ正規化する
Program Errorがなく、5評価軸がすべて確信度0.70以上のPASSならVALIDATED / ADVANCEとする
Program Error、AI Judgeの非PASS、または恒久方針変更候補があればHOLD / HOLDとし、公開へ進めない
機械用の状態・結果コードは維持し、人間向けにはhuman_guidance_jaで状態名、結果の意味、判断要否、求める判断、無回答時の扱いを日本語表示する
VALIDATED / ADVANCEは「検証合格：次の工程へ進めます」を意味し、公開承認や公開完了を意味しない
通常の検証不合格は「検証不合格：問題があるため保留します」と表示し、人間へ根拠補完や例外判断を求めない
恒久方針変更候補がある場合は「方針判断待ち：判断があるまで保留します」と表示し、選択肢と影響の確認を日本語で求める
恒久方針変更が本当に必要な場合だけ、問題と2件以上3件以下の選択肢・影響を保存し、人間のpolicy判断を要求する
Warningだけでは停止せずValidation Reportへ残す
同じ入力の再実行では成果物を書き換えない
O-09は新しい調査、意味を変える本文修正、公開配置、英訳、画像生成を行わない

O-10 Prepare Reviewの実行#

O-10は検証済みDraftへ公開用metadataを付け、日本語Review PacketとDraft PR準備情報を保存する。O-10自身はGitHub認証、commit、push、PR作成、mergeを実行しない。

rye run python -m note.knowledge_harness.prepare_review `
  --validated-draft-file _notes/knowledge_harness/validations/run-20260811-002/validated_draft.rst `
  --validation-report-file _notes/knowledge_harness/validations/run-20260811-002/validation_report.json `
  --plan-file _notes/knowledge_harness/plans/run-20260811-002/article_plan.json `
  --packet-file _notes/knowledge_harness/packets/run-20260811-002/evidence_packet.json `
  --proposal-file review-proposal.json

review-proposal.jsonは次の形式にする。

{
  "review_version": "review-v1",
  "preparer_id": "preparer-example",
  "final_title_ja": "変更を安全に確認する方法",
  "slug": "safe-change-review",
  "tags": ["運用", "検証"],
  "category_ja": "運用改善",
  "author": "mtakagishi"
}

既定では次の成果物を保存する。

docs/blog/posts/YYYY-MM-DD-slug.rst
_notes/knowledge_harness/reviews/<run_id>/review_packet.json

検証と生成の規則は次のとおり。

同じrun_idのVALIDATED / ADVANCE、修正済みDraft、Article Plan、Evidence Packetだけを受け付ける
修正済みDraftのSHA-256をValidation Reportと照合する
slugは小文字英数字をハイフンで区切り、タグは空・重複を許可しない
Asia/Tokyo基準の実行日より後で、既存ファイル名とpost directiveに使われていない最初の日を公開日にする
再実行時は同じrun_idのReview Packetに保存した公開日を再利用する
検証済み本文の意味を変更せず、最終タイトル、post directive、公開候補状態、公開日だけを反映する
post directiveにはタグ、カテゴリ、著者、:language: jaを付ける
Review Packetへ公開候補と全入力のパス・SHA-256、中心メッセージ、根拠参照、不確実性、検証結果を保存する
人間向け状態は「公開候補の確認待ち」とし、まだ公開承認されていないことを日本語で説明する
「公開を承認する」「今回だけ修正を求める」「公開しない」「今後の方針として検討する」の4選択肢と影響を日本語で示す
回答がない場合は公開せず保留することを明記する
pr_preparation.dedupe_keyをrun_idとし、一実行につき一つのDraft PRを外側の実行主体が作れる情報を保存する
正常時はREVIEW_READY / ADVANCEとし、required_human_actionをpublicationとする
同じ入力の再実行では公開候補とReview Packetを書き換えない
O-10は本文修正、新しい調査、英訳、画像、レビュー判断、公開承認を行わない

O-11 Decide Publicationの実行#

O-11は外側のGitHub実行主体が取得したPR snapshotと、人間が日本語表示から選んだ構造化判断を検証し、Publication Decisionを保存する。GitHub操作自体は行わない。

rye run python -m note.knowledge_harness.decide_publication `
  --review-packet-file _notes/knowledge_harness/reviews/run-20260811-002/review_packet.json `
  --article-file docs/blog/posts/2026-08-12-safe-change-review.rst `
  --pr-snapshot-file publication-pr.json `
  --human-decision-file publication-decision-input.json `
  --repository mtakagishi/note `
  --pr-number 99 `
  --base main `
  --authorized-actor mtakagishi

PR snapshotにはrepository、number、base、head、head_sha、url、merged、merged_by、merge_commit_shaを含める。人間判断はdecisions配列へ一件だけ指定し、decisionはrevision、reject、policy_candidateのいずれかとする。判断者、日時、理由、参照URL・ID、対象commit SHAを必須とする。

merge済みPRでは人間判断ファイルを渡さず、許可actorのmerged_byとmerge_commit_shaを確認してAPPROVED / ADVANCEとする
修正要求はinstruction_ja、target_jaを必須とし、REVISION / ADVANCEでO-12へ渡す
棄却はHOLD / HOLDでO-13へ渡し、追加の人間判断を要求しない
恒久方針候補は問題と2〜3選択肢・影響を必須とし、公開せずHOLD / HOLDとする
無回答、複数判断、mergeとの矛盾、対象外actor、対象commit不一致は公開せずHOLD / HOLDとする
自由文を判断種別へ推測変換せず、対象PRのrepository、番号、base、head、記事SHA-256を照合する
結果の意味と次の処理はhuman_guidance_jaへ日本語で保存する
同一入力の再実行ではpublication_decision.jsonを書き換えない

O-12 Apply Feedbackの実行#

O-12はO-11で明示された今回限りの修正要求だけを、指定されたDraftブロックへ反映する。自由文から対象を推測せず、新しい調査や根拠追加は行わない。

rye run python -m note.knowledge_harness.apply_feedback `
  --decision-file _notes/knowledge_harness/decisions/run-20260811-002/publication_decision.json `
  --draft-file _notes/knowledge_harness/drafts/run-20260811-002/draft.rst `
  --manifest-file _notes/knowledge_harness/drafts/run-20260811-002/draft_manifest.json `
  --proposal-file feedback-proposal.json

feedback-proposal.jsonはPublication Decisionの指示・対象をそのまま指定し、変更するブロックだけを列挙する。

{
  "instruction_ja": "冒頭を簡潔にしてください。",
  "target_ja": "冒頭段落",
  "changes": [
    {
      "block_id": "block-001",
      "body_rst": "要点を簡潔に示す冒頭です。",
      "packet_refs": ["topics/topic-001/items/item-001"]
    }
  ]
}

既定では次の成果物を保存する。

_notes/knowledge_harness/revisions/<run_id>/revised_draft.rst
_notes/knowledge_harness/revisions/<run_id>/revision_manifest.json

検証と生成の規則は次のとおり。

同じrun_idのREVISION / ADVANCE、正常なO-08初稿またはO-12改稿だけを受け付ける
DraftのSHA-256、今回限りの適用範囲、修正指示、対象、GitHub参照を照合する
修正文案に明示された既存block_idだけを変更し、本文をDraft内で一意に特定する
未指定ブロックと既存Packet参照は変更せず、新しい節、主張、根拠、危険なdirectiveを追加しない
変更ごとに修正前後SHA-256、指示、対象、Packet参照、GitHub参照を保存する
AI修正は同一記事2回までとし、3回目は実行せずHOLD / HOLDとする
正常時はREVISED / ADVANCEと「修正しました。再検証します」を保存し、O-09へ戻す
O-09はO-08のDRAFT_READYとO-12のREVISEDを同じ検査基準で再検証する
同一入力の再実行ではRevised Draftとrevision manifestを書き換えない
O-12は公開候補への再配置、GitHub操作、公開承認、恒久方針採用を行わない

Knowledge Harness Operations#

状態の正本#

作業開始#

状態更新#

HANDOFF#

再開プロンプト#

ChatGPT / Codex Work#

VS Code#

不一致や判断待ち#

記事処理パイプラインとの境界#

O-13 Record Outcomeの実行#

O-01 Capture Requestの実行#

O-02 Authorize Runの実行#

O-03 Screen Safetyの実行#

O-04 Collect Evidenceの実行#

O-05 Build Evidence Packetの実行#

O-06 Judge Candidateの実行#

O-07 Plan Articleの実行#

O-08 Draft Articleの実行#

O-09 Validate Draftの実行#

O-10 Prepare Reviewの実行#

O-11 Decide Publicationの実行#

O-12 Apply Feedbackの実行#

Recent Posts

Tags

Categories

Archives