auto-paper

name	auto-paper
description	全自動論文撰寫 + 閉環自我改進系統。 LOAD THIS SKILL WHEN: 全自動寫論文、auto write、自動撰寫、幫我寫完整篇、autopilot、從頭到尾、一鍵寫論文 CAPABILITIES: 編排所有研究 Skills + 3 層 Audit Hooks + Meta-Learning 自我改進

全自動論文撰寫 + 閉環自我改進

閉環架構

Instructions (AGENTS.md) → Skill (auto-paper) → Writing (drafts/) → Hooks (audit) → 回頭更新 Skill/Instructions

核心理念（CONSTITUTION §22）：可審計、可拆解、可重組。詳見 AGENTS.md。

四個審計維度：

維度	檢查	更新對象
Paper	引用、字數、Anti-AI	draft_action(action="patch") 修正論文
Methodology	方法學可再現性	補充方法學細節
Compliance	Agent 是否遵循流程	.memory/ 記錄偏差
Meta	Skill/Hook/Instruction	更新 SKILL/Hook/AGENTS

---

執行審計軌跡（Audit Trail）

每次執行在 projects/{slug}/.audit/ 產出：

檔案	內容
pipeline-run-{ts}.md	Phase 摘要 + Hook 統計 + Decision Log
search-strategy.md	搜尋策略和結果
reference-selection.md	文獻篩選決策
concept-validation.md	Novelty 驗證過程
hook-effectiveness.md	Hook 觸發率/通過率/誤報率
quality-scorecard.md	方法學 + 文字品質（0-10 分）
checkpoint.json	斷點恢復：last_completed_phase, phase_outputs

恢復邏輯：偵測 checkpoint.json → 詢問從 Phase N+1 繼續或重來。

---

雙重 Hook 系統

Copilot Hooks（A-D，寫作時即時修正）定義於本檔。 Pre-Commit Hooks（P1-P8 + G1-G7）定義於 git-precommit/SKILL.md。 兩者互補：Copilot 處理細節，Pre-Commit 處理全局。

---

🚧 Hard Gate Enforcement（Code-Level，不可跳過）

SKILL.md 是 soft constraint（Agent 可能忽略）。以下 MCP Tools 是 code-enforced hard limits。

必要 MCP Tool 呼叫

時機	MCP Tool	說明
每個 Phase 完成後	pipeline_action(action="validate_phase", phase=...)	返回 PASS/FAIL + 缺少的 artifact，FAIL 則禁止進入下一 Phase
Phase 7 每輪開始	pipeline_action(action="start_review")	啟動 AutonomousAuditLoop 狀態機，返回 round context
Phase 7 每輪結束	pipeline_action(action="submit_review", scores=...)	提交分數，返回 verdict (CONTINUE/QUALITY_MET/MAX_ROUNDS/REWRITE_NEEDED)
Phase 7 需要大幅重寫	pipeline_action(action="rewrite_section", sections=..., reason=...)	回退到 Phase 5 重寫指定 section，最多 2 次回退
Phase 5 每 section 完成後	pipeline_action(action="approve_section", section=..., decision=...)	Autopilot: Agent 自我審閱後自動 approve。手動: 用戶審閱 → approve 或 revise。Phase 5 gate 要求全部 approved
用戶要求暫停時	pipeline_action(action="pause", reason=...)	暫停 pipeline，記錄 draft hash 以偵測用戶編輯
暫停後恢復	pipeline_action(action="resume")	恢復 pipeline，偵測用戶修改並建議重新驗證
Pipeline 中途任意時刻	pipeline_action(action="heartbeat")	返回全 Phase 狀態 + 剩餘工作項，Agent 無法自稱 "done"
Agent 需要一次總檢查時	pipeline_action(action="doctor")	返回 11-phase readiness、外部 MCP 宣告/command 可用性、最近 gate cache
Phase 5 每次 Hook 評估後	record_hook_event(hook_id, event_type)	記錄 A/B/C/E Hook 的 trigger/pass/fix/false_positive，Phase 6 gate 會驗證有實際記錄
Phase 6 之前（審計階段）	run_quality_checks(action="quality_audit", scores=...)	設定 ≥4 維度品質分數 + 產生 scorecard/hook-effectiveness 報告，Phase 6 gate 驗證分數數據
Phase 10 之前（自我改進）	run_quality_checks(action="meta_learning")	執行 D1-D9 分析 + 寫入 meta-learning-audit.yaml / meta-learning-feedback.yaml，Phase 10 gate 驗證 analysis_steps

強制執行規則

1. Phase 轉換：Agent MUST call pipeline_action(action="validate_phase", phase=N) 且收到 PASS，才能開始 Phase N+1
2. Phase 7 Review Loop：Agent MUST call pipeline_action(action="start_review") 開始、pipeline_action(action="submit_review", scores=...) 結束。不可跳過輪次
3. Pipeline 完成：Agent MUST call pipeline_action(action="heartbeat") 確認 completion = 100% 才能宣稱完成
4. 所有 gate 結果自動記錄到 .audit/gate-validations.jsonl，可供 Phase 10 D-Hook 分析
5. 專案結構驗證：validate_project_structure() 可獨立於 pipeline 呼叫，用於檢查新/既存專案結構完整性
6. Phase > 1 自動前提檢查：pipeline_action(action="validate_phase", phase=...) 在 Phase > 1 時會自動檢查前置 Phase 的關鍵 artifacts（WARNING 級別）
7. 審計數據強制：Phase 6 gate 不只檢查報告檔案存在，還驗證 quality-scorecard.yaml（≥4 維度、avg > 0）和 hook-effectiveness.yaml（≥1 hook 有事件記錄）
8. 自我改進數據強制：Phase 10 gate 驗證 meta-learning-audit.yaml 有完整分析記錄（analysis_steps D1-D9、adjustments_count、lessons_count、suggestions_count 與 count/list 一致性），並產出 meta-learning-feedback.yaml 供下一輪 Agent 直接接續

🛡️ Anti-Compaction 恢復協議

Context compaction 會導致 Agent 遺失 pipeline 進度與寫作狀態。以下防線自動保護：

第一層：Pipeline 狀態自動寫入

• 所有 gate tools（pipeline_action(action="validate_phase"), pipeline_action(action="heartbeat"), pipeline_action(action="start_review"), pipeline_action(action="submit_review")） 完成後自動寫入 projects/{slug}/.mdpaper-state.json 的 pipeline_state 欄位
• 不需要 Agent 額外操作

第二層：寫作進度自動寫入（✍️ Writing Session Checkpoint）

• draft_action(action="write") 和 draft_action(action="patch") 成功後，自動寫入 writing_session 欄位
• 記錄：當前 section、檔名、操作類型、字數、所有已存在 section 列表
• 不需要 Agent 額外操作

第三層：Agent 主動詳細檢查點

• 使用 workspace_state_action(action="checkpoint", section=..., plan=..., notes=..., references_in_use=...) 儲存推理狀態
• 建議時機：每個段落開始前、切換 section 前、引用大量文獻時
• 儲存：寫作大綱、風格決策、正在使用的引用 key、Agent 的思考筆記
• 此工具呼叫輕量，不影響寫作流程

第四層：自動恢復

• workspace_state_action(action="get") 讀取 per-project state → get_recovery_summary() 產出 banner
• Pipeline banner：current phase, round, gate result, next action, failures
• Writing session banner（✍️）：current section, file, word count, agent context, sections on disk
• 恢復後使用 draft_action(action="read") 讀回草稿內容即可繼續

第五層：Agent 強制規則

• 對話開始（或 context compaction 後首次回應）→ MUST call workspace_state_action(action="get")
• 如果 pipeline_state.is_active == true → 直接從 recovery summary 指示的 Phase/Round 繼續
• 如果 writing_session.active == true → 用 draft_action(action="read") 讀回草稿，繼續寫作
• 禁止從頭重跑已 PASS 的 Phase

---

13 Main Gate Checkpoint Pipeline（Phase 0-11 + 6.5；Phase 2.1 為獨立 sub-gate）

Phase 0: PRE-PLANNING（Source Materials + Journal Profile + Pipeline Config）🆕

目的：在任何寫作開始前，先登記用戶提供的原始素材，再建立結構化的期刊約束 + Pipeline 行為設定。 產出：projects/{slug}/journal-profile.yaml + projects/{slug}/.audit/source-materials.yaml

── Step 0: 掃描用戶原始素材（不可略過）──
  1. 呼叫 `project_action(action="source_materials")`
     - 預設掃描 workspace root，排除 projects/src/tests/node_modules 等 generated/code trees
     - 偵測 `.docx`, `.xlsx`, `.xls`, `.csv`, `.tsv`, `.pdf`, `.rtf`, `.pptx`, `.txt`
     - 產出 `.audit/source-materials.yaml` 和 `.audit/source-materials.md`
  2. 若 manifest 有 `pending_asset_aware > 0`：
     - 對 `agent_next_steps.asset_aware_file_paths` 呼叫 asset-aware `ingest_documents`
     - 表格型 DOCX/XLSX 必須先轉成 context，不能只根據摘要腦補
     - 後續 Phase 4/5 的 asset plan / results drafting 必須以這些 primary_user_material 為優先證據
  3. 即使沒有找到素材，也必須保留 0-candidate manifest，證明 agent 已掃描過 workspace。

── Step 1: 資訊來源 ──
Agent 按優先順序取得期刊要求：
  a) 用戶提供 submission guide / for-authors PDF/URL
     → 解析文件 → 自動填入 YAML（需用戶確認）
  b) 用戶口頭說明（例：「BJA, original research, 3000字」）
     → Agent 先查 templates/journal-profiles/ 內建期刊庫（麻醉學 Top 20）
     → 有匹配 → 讀取 YAML → 複製到專案 → 用戶確認
     → 無匹配 → 從 template 建立 + 補全欄位
  c) 無明確期刊 → 使用 paper_type 預設值
     → 產出 YAML 後提醒用戶日後補充

  💡 提醒用戶：可直接請 Copilot 讀取內建期刊設定（templates/journal-profiles/），
     例如「幫我套用 BJA 的設定」即可自動產生 journal-profile.yaml。
     用 read_file 閱讀 _index.yaml 可查看所有 20 個可用期刊。

── Step 2: 產生 journal-profile.yaml ──
  1. 從 templates/journal-profile.template.yaml 複製模板
  2. 填入期刊資訊、字數限制、圖表上限
  3. 設定 pipeline 行為（loop 上限、review 輪數）
  4. 設定 reporting guidelines checklist
  5. 🗣️ 呈現 YAML 摘要給用戶確認
     → 特別強調：字數上限、圖表上限、必要文件、loop 設定

── Step 3: 解析 submission guide（如有）──
  IF 用戶提供 submission guide 文件：
    a) 讀取文件內容（PDF/URL）
    b) 提取結構化資訊：
       - 字數限制（total + per section）
       - 圖表限制（數量 + 格式 + DPI）
       - 引用格式 + 上限
       - 必要文件清單
       - 報告指引要求
    c) 填入 YAML 對應欄位
    d) 標註 ⚠️ 不確定的欄位 → 請用戶確認

journal-profile.yaml 對全 Pipeline 的約束

YAML 欄位	影響的 Phase / Hook
paper.type	Phase 1 專案設定, Phase 4 寫作順序
paper.sections	Phase 4 大綱, Phase 5 寫作順序
word_limits.*	Hook A1 字數, Hook C6 總字數
assets.figures_max/tables_max	Phase 4 Asset Plan, Phase 5 Asset 生成
references.max_references	Phase 2 文獻數量, Phase 8 引用上限
references.reference_limits	按論文類型的引用上限（覆蓋 max_references）
references.style	Phase 8 引用格式
reporting_guidelines.checklist	Hook B5 方法學, Hook C2 投稿清單
required_documents.*	Phase 9 匯出, Hook C2 投稿清單

source-materials.yaml 對全 Pipeline 的約束

YAML 欄位	影響的 Phase / Hook
summary.total_candidates	Phase 0 是否已實際掃描用戶素材
materials[].evidence_priority	Phase 3 concept、Phase 4 plan、Phase 5 results/methods
materials[].ingestion.status	Phase 2.1/Phase 5 是否需先用 asset-aware 解析 DOCX/XLSX
agent_next_steps.asset_aware_file_paths	Agent 必須呼叫 asset-aware 的具體 file list
agent_next_steps.asset_aware_required	防止只讀摘要、漏讀正式表格/資料檔

Data Anchor Provenance Rule：data-artifacts.yaml 的 data_anchors 不得以 concept.md、agent summary、inferred/estimated 值作為來源。每個數字/統計 anchor 必須引用 ready/ingested source_material_id、asset_aware_doc_id、data_artifact_id，或可信 data file；若來源素材仍是 pending_asset_aware，Hook F4 必須 CRITICAL fail。 | pipeline.hook_*_max_rounds | Hook A/B/C cascading 上限 | | pipeline.review_max_rounds | Phase 7 Autonomous Review 輪數 | | pipeline.writing.anti_ai_* | Hook A3 Anti-AI 嚴格度 | | pipeline.writing.citation_density | Hook A2 引用密度標準 | | pipeline.assets.* | Phase 5 Asset Sub-Pipeline 行為 | | pipeline.autopilot | 全自動模式（預設 true） |

Autopilot 模式（預設開啟）

pipeline:
  autopilot: true # 預設全自動，用戶可設 false 啟用逐步審閱
  autopilot_pause_at: [] # 用戶可指定暫停點，例如 ["phase4", "phase5_section", "phase7_rewrite"]

autopilot 設定	行為
true（預設）	Agent 全程自主決策、自我審閱、自我修正，僅在安全閥觸發時詢問用戶
false	每個 Phase 確認點都詢問用戶（傳統模式）
autopilot_pause_at	指定特定暫停點（精細控制），例如 Phase 4 確認大綱、Phase 5 逐 section

安全閥（即使 autopilot=true 也會詢問用戶）：

• concept score < 75 且自動修正 2 次仍未達標
• Phase 6 cascading fix 3 rounds 後仍有 CRITICAL
• Phase 7 達 max_rounds 且品質未達標
• regression_count > 2（防止無限循環）

Gate: journal-profile.yaml 存在 + 用戶已確認關鍵欄位（字數、圖表上限）

---

Phase 1: PROJECT SETUP

Skill: project-management

1. project_action(action="current") → 有專案就切換，沒有就建立
2. project_action(action="create", name, paper_type) 或 project_action(action="switch", slug)
3. project_action(action="setup")
4. 載入 journal-profile.yaml → 驗證 paper_type 一致
5. project_action(action="update", target_journal=journal.name)
6. workspace_state_action(action="sync", doing="phase 1 setup", next_action="phase 2 literature")

Gate: 專案存在 + paper_type 與 journal-profile 一致

---

Phase 2: LITERATURE SEARCH

Skill: literature-review, parallel-search 外部 MCP: pubmed-search, zotero-keeper（optional）

1. generate_search_queries(topic, strategy="comprehensive")
2. 並行 unified_search() × 3-5 組
3. 以 read_session(action="pmids") 取回 PMID，並以 PMID/DOI 去重
4. get_citation_metrics(sort_by="relative_citation_ratio")
5. 選前 15-20 篇 → save_reference_mcp(pmid, agent_notes)
6. [Optional] Zotero: search_items(query) → 取 PMID → save_reference_mcp()

Gate: Paper-type-aware 最低文獻數（Code-Enforced）

Paper Type	最低文獻數
original-research	20
review-article	30
systematic-review	40
meta-analysis	40
case-report	8
letter	5
fallback	15

解析優先序：journal-profile.yaml references.minimum_reference_limits → DEFAULT_MINIMUM_REFERENCES → DEFAULT_MIN_REFERENCES (15)

自動決策：< minimum → expand_search_queries；>500 → 加 MeSH 限縮；用戶有 Zotero → 主動問匯入。

---

Phase 2.1: FULLTEXT INGESTION & ASSET EXTRACTION

Skill: literature-review 外部 MCP: asset-aware-mcp, pubmed-search 輸入: Phase 2 儲存的文獻（須達 paper-type-specific 最低數量） 輸出: 每篇文獻的全文解析結果 + analysis.json + references/fulltext-ingestion-status.md

核心原則: 引用文獻前必須閱讀全文並完成結構化分析。僅依據 abstract/metadata 不足以支撐 Methods/Results/Discussion 的引用。

Context Isolation: 每篇論文由獨立 subagent 閱讀分析，避免 20+ 篇全文汙染主 agent context。

流程：

1. list_saved_references() → 取得所有已儲存文獻清單
2. 對每篇文獻： a. 查詢 PDF 來源：get_fulltext(pmcid) （pubmed-search MCP）或 analyze_fulltext_access(pmids) 確認 Open Access 狀態 b. IF 全文可取得：
   • 取得全文：pubmed-search get_fulltext(pmcid, sections="all") 或下載 PDF
   • 解析全文：asset-aware ingest_documents(file_paths=[pdf_path], use_marker=true)
   • 等候處理：get_job_status(job_id) 直到完成
   • 建立索引：inspect_document_manifest(doc_id) 取得完整資產清單
   • 提取關鍵段落：get_section_content(doc_id, section_path) → Methods, Results, Discussion
   • 更新 metadata.json：加入 fulltext_ingested: true, asset_aware_doc_id, fulltext_sections c. IF 全文不可取得：
   • 記錄原因：metadata.json 加入 fulltext_ingested: false, fulltext_unavailable_reason: "..."
   • ⚠️ 此文獻在寫作時僅能引用其 abstract 中的結論性資訊，不可引用具體方法或數據
3. Subagent 閱讀分析（CRITICAL — 每篇一個 subagent）： a. 主 Agent 呼叫 get_reference_for_analysis(pmid) → 取得結構化全文包（≤30K 字元） b. 用 runSubagent 啟動獨立 subagent，prompt 包含：
   • 全文內容（步驟 a 的結果）
   • 分析指令：摘要、方法學評估、關鍵發現、限制、可用於文章哪些章節
   • 要求 subagent 呼叫 save_reference_analysis(pmid, summary, methodology, key_findings, limitations, usage_sections, relevance_score) c. Subagent 完成後，analysis.json 已寫入 reference 目錄，metadata.json 標記 analysis_completed: true d. 主 Agent 後續寫作時只使用 analysis_summary，不再重讀全文 → 零 context 汙染
4. 產出 references/fulltext-ingestion-status.md：

PMID	標題	全文狀態	Asset-Aware	分析狀態	可用章節	備註
...	...	✅	doc_abc	✅	I/M/R/D
...	...	❌	—	⚠️	I only	非 OA

Gate: fulltext-ingestion-status.md 已建立 + 每篇文獻標記全文狀態 CRITICAL Gate: 所有文獻必須有 analysis_completed: true（Pipeline Gate Phase 2.1 強制檢查） WARNING Gate: 若 >50% 文獻無全文 → 提醒用戶考慮補充 OA 文獻

---

Phase 2 advisory task: CRITICAL APPRAISAL

輸入: Phase 2 + 2.1 完成的文獻（含全文解析結果） 輸出: references/appraisal-matrix.md

目的：在進入概念階段前，對核心文獻做品質評估，避免在低品質證據上建構研究。 requires: Phase 2.1 完成（全文解析結果可用時，品質評估更精確）

1. 對每篇核心文獻（≥5 篇）評估：

   • 研究設計品質（RCT > cohort > case series > case report > expert opinion）
   • 偏差風險（selection, performance, detection, attrition, reporting）
   • 樣本量適足性
   • 統計方法適當性
   • 結論是否有資料支持
   • [NEW] 全文驗證狀態：是否已透過 asset-aware 閱讀全文？未讀全文的文獻標記 ⚠️

2. 產出品質矩陣（appraisal-matrix.md）：

PMID	1st Author	Design	Quality	Bias Risk	Key Limitation
...	...	RCT	High	Low	...

3. 標記低品質文獻（Quality = Low），概念階段不應過度依賴

Advisory checkpoint: appraisal-matrix.md 已建立，至少 5 篇已評估；正式 gate 仍是 Phase 2 / Phase 2.1 / Phase 3。

---

Phase 3: CONCEPT DEVELOPMENT

Skill: concept-development 外部 MCP: cgu（when novelty needs boost）

1. 分析 saved references → 識別 Gap
2. 撰寫 concept.md（含 🔒 NOVELTY + 🔒 SELLING POINTS）
3. draft_action(action="write", filename="concept.md", content=..., skip_validation=True)
4. validation_action(action="concept")(project=...)
5. IF score < 75:
   • 自動修正 1 次 → 再驗證
   • 仍 < 75 → CGU: deep_think / spark_collision / generate_ideas → 修正 → 再驗證
   • 仍 < 75 → STOP，回報用戶（附 CGU 建議）

Gate: concept score ≥ 75 OR 用戶明確說「繼續」

CGU 工具對應：

問題	CGU 工具	產出
找弱點	deep_think	Reviewer 攻擊角度
找論點	spark_collision	碰撞新穎角度
廣泛發想	generate_ideas	3-5 個 novelty 候選
多觀點	multi_agent_brainstorm	多角色辯論

---

Phase 4: MANUSCRIPT PLANNING

產出物：manuscript-plan.yaml（存在 projects/{slug}/ 下）

1. 讀取 concept.md + saved references + journal-profile.yaml
2. 產出 manuscript-plan.yaml（段落級 Section Brief）：
   • writing_order: 依 journal-profile.paper.sections，fallback 到 paper type 預設
   • sections: 每個 section 包含 word_budget + paragraphs[]
     • 每段：id, function, topic, key_claims, must_cite, word_target
     • 🔒 保護段落標記 protected: true（Novelty Statement / Selling Points）
     • Methods 段落可含 checklist_items（對應 B5 方法學）
   • asset_plan: 圖/表/流程圖（含 tool, tool_args, caption, caption_requirements）
     • ⚠️ 驗證總數 ≤ assets.figures_max + assets.tables_max
     • ⚠️ 驗證 ≤ assets.total_display_items_max
   • submission_checklist: 依 required_documents.* 列出需準備項目
   • metadata: generated_at, based_on, changelog[]
3. Plan 修改規則：
   • Agent 可新增段落 / 修改 claims / 調字數 → 需寫入 metadata.changelog
   • Agent 禁止刪除 protected: true 段落
   • 用戶自由修改，changelog 自動追蹤
4. Autopilot 模式（pipeline.autopilot: true，預設）：
   • Agent 自行驗證 plan 的完整性（圖表數量、字數預算、section 涵蓋度）
   • 驗證通過 → 直接存入 projects/{slug}/manuscript-plan.yaml → 繼續 Phase 5
   • 驗證失敗 → Agent 自行修正 → 重新驗證（最多 2 輪）→ 仍失敗才詢問用戶
   • Plan 摘要記入 .audit/pipeline-run-{ts}.md，用戶可事後查閱
5. 手動模式（pipeline.autopilot: false 或 autopilot_pause_at 含 "phase4"）：
   • 🗣️ 呈現 manuscript-plan.yaml 摘要給用戶確認
   • 用戶調整 → 確認 → 存入

Gate: manuscript-plan.yaml 存在 + 圖表數量不超限

寫作順序（依 journal-profile.paper.sections，fallback 到 paper type 預設）：

Paper Type	建議順序
original-research	Methods → Results → Introduction → Discussion → Abstract
systematic-review	Methods → Results → Discussion → Introduction → Abstract
case-report	Case Presentation → Discussion → Introduction → Abstract

---

Phase 4 advisory task: SUPPLEMENTARY PLANNING

輸入: manuscript-plan.yaml（Phase 4 產出） 輸出: manuscript-plan.yaml 更新（新增 supplementary 區段）

目的：在撰寫前規劃補充材料（Supplementary Materials），避免主稿完成後才回頭補。

1. 根據期刊 profile 判斷是否需要補充材料

2. 規劃補充內容：

   • Supplementary Tables（大型數據表、子群分析）
   • Supplementary Figures（額外結果圖）
   • Supplementary Methods（詳細方法學、程式碼）
   • 敏感度分析結果
   • EQUATOR checklist 完整版（如 CONSORT flow diagram）

3. 在 manuscript-plan.yaml 加入 supplementary 區段：

supplementary:
  - id: S1
    type: table
    title: "Baseline characteristics by subgroup"
    linked_section: Results
  - id: S2
    type: figure
    title: "Sensitivity analysis forest plot"
    linked_section: Results

4. 建立 supplementary/ 目錄結構

Advisory checkpoint: manuscript-plan.yaml 含 supplementary 區段（可為空 = 無需補充材料）；正式 gate 仍是 Phase 4。

---

Phase 4 advisory task: SUB-SECTION WRITING TEMPLATES（段落級寫作指引）

目的：補充 Phase 4 manuscript-plan.yaml 的段落級先驗知識。Agent 在 Phase 5 撰寫每段時必須對照以下模板，確保結構完整、邏輯連貫。

Introduction 段落模板（Funnel Structure）

段落	功能	內容要求	引用要求	Hook 檢查
P1	Broad Context	研究領域的重要性、流行病學資料、臨床意義	≥2 引用（流行病學/指引）	B12（context markers）
P2	Evidence Review	既有文獻的主要發現、方法、結論	≥3 引用（核心文獻）	A2（citation density）
P3	Knowledge Gap	現有文獻的不足、矛盾、未解問題	≥1 引用（指出 gap 來源）	B12（gap markers）
P4	Study Objective	本研究的目的、假說（若適用）	0-1 引用	B12（objective markers）

Anti-patterns（自動 FLAG）：

• P1 直接跳到研究目的（缺 context/gap）
• P2 只列名字不描述內容（name-dropping）
• P3 缺乏具體 gap statement（如 "however, ... remains unclear"）
• P4 超過 2 句（過度冗長的目的聲明）

Methods 段落模板（Reproducibility Structure）

段落	功能	內容要求	引用要求	Hook 檢查
M1	Study Design	研究類型、期間、機構、IRB 核准	≥1（設計依據）	B14（ethical statements）
M2	Participants	納入/排除標準、樣本大小計算	≥1（criteria 依據）	B9（past tense）
M3	Intervention/Exposure	介入措施的詳細描述、對照組定義	≥1（intervention protocol）	B5（方法學 checklist）
M4	Outcome Measures	主要/次要結果指標、測量方式、定義	≥2（validated instruments）	C11（Methods 引用）
M5	Statistical Analysis	統計方法、軟體版本、顯著水準	≥1（統計方法引用）	B8（data-claim alignment）

Anti-patterns：

• M1 缺 IRB/倫理核准 → B14 CRITICAL
• M2 無樣本大小依據 → WARNING
• M5 統計方法與 Results 不一致 → B8 CRITICAL

Results 段落模板（Data-First Structure）

段落	功能	內容要求	引用要求	Hook 檢查
R1	Study Flow / Demographics	篩選流程、基本特徵（→ Table 1）	0（純數據）	C13（圖表引用）
R2	Primary Outcome	主要結果、統計檢驗、效果量 + CI	0（純數據）	B11（客觀性）、B16（效果量）
R3	Secondary Outcomes	次要結果、亞群分析	0-1（方法引用）	B8（統計對齊）
R4	Subgroup / Sensitivity	子群分析、敏感度分析（若適用）	0（純數據）	C13（圖表引用）

Anti-patterns：

• R1-R4 含有 interpretive language（"suggesting", "indicating"）→ B11 WARNING
• Results 無任何圖表引用 → C13 WARNING
• 效果量缺 CI → B16 WARNING

Discussion 段落模板（Interpretation Structure）

段落	功能	內容要求	引用要求	Hook 檢查
D1	Main Findings	總結主要發現（不重複 Results 數字）	0-1	B13（main finding markers）
D2-D3	Literature Comparison	與既有文獻的一致/矛盾之處	≥3（比較文獻）	C11（Discussion 引用分布）
D4	Mechanisms / Implications	可能機制解釋、臨床/實務意義	≥1（機制文獻）	B13（implications markers）
D5	Limitations	研究限制（設計、偏差、外推性）	0-2	B13（CRITICAL if missing）
D6	Conclusion / Future	總結 + 未來研究方向	0-1	B15（hedging 適當用量）

Anti-patterns：

• D1 重複 Results 的統計數字 → WARNING
• D2-D3 無引用（未與文獻比較）→ C11 CRITICAL
• D5 缺席 → B13 CRITICAL
• 全文 hedging 過度（> 6/1000 words）→ B15 CRITICAL

Abstract 段落模板（Structured Abstract）

段落	功能	字數目標	內容要求
A1	Background	40-60 words	背景 + gap（1-2 句）
A2	Methods	60-80 words	設計、樣本、主要測量
A3	Results	80-120 words	主要結果 + 統計數字
A4	Conclusions	30-50 words	臨床意義（1-2 句，避免 overgeneralization）

注意：Abstract 字數受 journal-profile.yaml 嚴格限制。

圖表插入規範（與 C13 Hook 整合）

規則	說明	Hook
順序引用	Figure 1 必須在 Figure 2 之前首次出現	C13
Caption 完整	≥10 words，含 axes/variables/abbreviations	C13
Results 必有	Results 有數據 claim → 必須引用至少 1 個圖/表	C13
Orphan 檢測	Manifest 有但文中未引用 → WARNING	C7d
Phantom 檢測	文中引用但 Manifest 無 → CRITICAL	C7d
數量限制	不超過 journal-profile 設定的 max	C7a

Citation Decision Record 規範（與 C12 Hook 整合）

每篇引用的文獻必須在 citation_decisions.json 中留下決策紀錄：

{
  "smith2023_12345678": {
    "justification": "Largest RCT comparing X vs Y in same population, supports our primary outcome finding",
    "cited_sections": ["Introduction", "Discussion"],
    "relevance_score": 9,
    "decision_date": "2025-01-15",
    "decided_by": "agent"
  },
  "jones2022_87654321": {
    "justification": "Validated the measurement instrument used in our study (M4 outcome measures)",
    "cited_sections": ["Methods"],
    "relevance_score": 8,
    "decision_date": "2025-01-15",
    "decided_by": "agent"
  }

工作流程：

1. Phase 2 → save_reference_analysis() 建立 usage_sections
2. Phase 5 → 每次 insert_citation() 時，同步更新 citation_decisions.json
3. Phase 6 → C12 Hook 驗證：每篇引用都有 justification + cited_sections 與實際吻合

---

Phase 5: SECTION WRITING（核心 + Cascading Audit Loop）

Skill: draft-writing 外部 MCP: drawio（diagrams）, cgu（Discussion）, data-tools（圖表） 輸入: manuscript-plan.yaml（Phase 4 產出）

plan = load("manuscript-plan.yaml")

FOR section IN plan.writing_order:

  brief = plan.sections[section]

  ── Step 1: 準備 ──
  1a. 讀取 brief.paragraphs + 已完成 sections + draft_action(action="available_citations")()
  1b. 讀取 plan.asset_plan[section] → 確認需要哪些圖表

  ── Step 2: Asset 生成（先於寫作，見下方 Asset Sub-Pipeline）──
  2a. IF plan.asset_plan 有該 section 的 asset:
      → 執行 Asset Generation Sub-Pipeline
      → 產出 asset manifest entries（圖表路徑 + caption）

  ── Step 3: 撰寫（段落級 Brief 引導） ──
  3a. IF Methods + asset_plan 有 diagram:
      → drawio.create_diagram → XML
      → drawio.export_diagram → PNG/SVG
      → project_action(action="save_diagram", project=..., content=..., rendered_content=..., rendered_format=...)
      → draft_action(action="insert_figure", filename=..., caption=..., draft_filename=..., after_section=...)
  3b. FOR paragraph IN brief.paragraphs:
      → 依據 paragraph.topic + key_claims + must_cite 撰寫
      → 尊重 paragraph.word_target
      → 若 paragraph.protected = true → 確保 🔒 內容完整
      → 若 paragraph.checklist_items → 逐條涵蓋
      → ✍️ 每段開始前呼叫 `workspace_state_action(action="checkpoint", section=..., plan=..., notes=..., references_in_use=...)`
        → 儲存寫作大綱與推理狀態，防止 compaction 遺失
  3c. draft_action(action="section") 或 draft_action(action="write")
      → 撰寫時整合 Step 2 產出的 asset references
      → ✅ 成功後自動 checkpoint 至 .mdpaper-state.json（無需手動）
  3d. IF Discussion + 論點弱:
      → cgu.deep_think → 強化邏輯鏈

  ── Step 4: Cascading Audit Loop（最多 3 rounds） ──
  4a. 🔔 HOOK A: post-write audit
      → Round 1: run A1-A4 → collect issues
        A1: 字數 vs brief.word_budget
        IF issues → draft_action(action="patch") 修正 → re-run A1-A4
      → Round 2: IF still issues → draft_action(action="patch")（不同策略）→ re-run
      → Round 3: IF still issues → LOG to .audit/ + FLAG for Phase 6

  4b. 🔔 HOOK B: post-section audit
      → run B1-B7 → collect issues
      → B7: Section Brief 合規（段落級比對 + caption_requirements，見 Hook B7 定義）
      → IF critical (B1 concept 不一致 / B2 🔒 缺失 / B5 <5):
        → targeted draft_action(action="patch") → re-run Hook A on patched areas (1 round)
        → re-run Hook B → IF still critical → FLAG for Phase 6
      → IF advisory only → LOG + continue

  ── Step 5: Agent 自主審閱 + 即時修正（Autopilot 預設行為）──

  **核心原則**：Agent 在寫完 section 後立即自我評估，發現問題就地修正，
  不需等到 Phase 7 Review 才回頭改。這才是真正的 autopilot。

  5a. Agent 自行評估 section 品質：
      - Hook A/B 結果 → 有無未解 CRITICAL/WARNING
      - 與 concept.md 的一致性
      - 與已完成 sections 的邏輯連貫性
      - 段落是否完整涵蓋 manuscript-plan.yaml 的 key_claims
  5b. IF 發現問題 → Agent 立即修正：
      - 針對性 draft_action(action="patch") → re-run 相關 Hook
      - 修正直到 0 CRITICAL，或達 cascading 上限後 FLAG for Phase 6
      - 決策和修正記入 `.audit/pipeline-run-{ts}.md`
  5c. 自我評估通過 → Agent 呼叫 `pipeline_action(action="approve_section", section=section, decision="approve")`
      → 自動標記 approved → 繼續下一個 section
  5d. **用戶可隨時介入**：
      - 用戶說「我要看一下」→ Agent 暫停，呈現 section 摘要
      - 用戶說「每個 section 都讓我看」→ Agent 對後續 section 切換為手動審閱模式

  **手動審閱模式**（`pipeline.autopilot: false` 或 `autopilot_pause_at` 含 `"phase5_section"`）：
  5e. 呈現 section 內容摘要（字數、主要論點、Hook A/B 結果）
  5f. 🗣️ 詢問用戶：「approve / 請修改（附具體意見）」
  5g. Agent 呼叫 `pipeline_action(action="approve_section", section=section, decision=action, feedback=feedback)`
  5h. IF action == "revise":
      → 根據 feedback 執行 draft_action(action="patch") / draft_action(action="write") 修正
      → re-run Hook A/B on modified content
      → 回到 5e 再次呈現（最多 3 輪修改）
  5i. IF action == "approve":
      → 繼續到下一個 section

    ⏸️ 暫停點：用戶可隨時說「暫停」→ Agent 呼叫 `pipeline_action(action="pause")`
     → 用戶自由編輯草稿
      → 用戶說「繼續」→ Agent 呼叫 `pipeline_action(action="resume")`
     → 根據修改偵測結果重新跑相關 Hook

  ── Step 6: 記錄 ──
  6a. Log section audit results 到 .audit/pipeline-run-{ts}.md
  6b. Log 到 .memory/progress.md
  6c. 更新 checkpoint.json: { last_section: section, audit_status }
  6d. IF plan 需修改 → 寫入 plan.metadata.changelog + 存檔

Asset Generation Sub-Pipeline（Phase 5 Step 2）

每個 section 寫作前，依 asset_plan 生成所需資產：

FOR asset IN asset_plan[section]:
  SWITCH asset.type:

    CASE "table_one":
      1. analysis_action(action="list_data") → 確認資料存在
      2. analysis_action(action="detect_variables", filename=file) → 自動分類
      3. analysis_action(action="table_one", filename=file, groups=..., variables=...) → 產出表格
      4. draft_action(action="insert_table", filename=..., table_content=..., caption=...) → 插入草稿
      → ❌ 無資料檔 → 提示用戶提供，SKIP asset

    CASE "statistical_test":
      1. analysis_action(action="summary", filename=file) → 了解資料分佈
      2. analysis_action(action="test", filename=file, test_type=...) → 執行檢定
      3. 結果整合到 section 文字中
      → ❌ 不確定檢定方法 → 詢問用戶

    CASE "plot":
      1. analysis_action(action="plot", filename=file, plot_type=...) → 產生圖片
      2. draft_action(action="insert_figure", filename=..., image_path=..., caption=...) → 插入草稿
      → ❌ 圖表不合理 → 提供替代建議

    CASE "flow_diagram":  (CONSORT, PRISMA, study flow)
      1. IF drawio MCP 可用:
         → drawio.create_diagram(type, data) → XML
        → drawio.export_diagram(format="png" or "svg") → rendered asset
        → project_action(action="save_diagram", project=..., content=..., filename=name, rendered_content=..., rendered_format=...)
        → draft_action(action="insert_figure", filename=..., caption=..., draft_filename=..., after_section=...)
      2. ELSE:
         → 產生 Mermaid 文字描述 → 存入 results/diagrams/
         → FLAG: 建議用戶手動轉換
      3. reference 在草稿中，確保導出的 Word/PDF 可見圖像而不只是 `.drawio` 原始檔

    CASE "custom_figure":
      1. Agent 依 asset_plan 說明 → analysis_action(action="plot") 或手動描述
      2. draft_action(action="insert_figure") 或 FLAG 需外部工具

Asset Type	必要 MCP Tool	外部 MCP	Fallback
table_one	analysis_action(action="table_one")	—	手動提供表格
statistical_test	analysis_action(action="test")	—	描述預期分析
plot	analysis_action(action="plot")	—	描述圖表需求
flow_diagram	project_action(action="save_diagram") + draft_action(action="insert_figure")	drawio 🔸	Mermaid 文字
forest_plot	❌ 缺少	meta-analysis 🔸	R/Python script
funnel_plot	❌ 缺少	meta-analysis 🔸	R/Python script
PRISMA_diagram	project_action(action="save_diagram") + draft_action(action="insert_figure")	drawio 🔸	Mermaid 文字

Agent-Initiated Asset Generation（寫作中自主新增圖表）

Phase 4 的 asset_plan 無法預見所有需求。寫作過程中 Agent 可能發現需要 文獻比較表、方法對照表 等。

觸發條件（Phase 5 Step 3 寫作中）：
  - 引用 ≥3 篇文獻做比較 → 考慮 literature_summary_table
  - 描述多種方法/技術差異 → 考慮 comparison_table
  - 概念或架構複雜 → 考慮 concept_diagram

流程：
  1. 檢查 journal-profile.yaml → pipeline.assets.agent_initiated.enabled
  2. 檢查類型是否在 allowed_types 中
  3. 檢查目前圖/表數量是否已達 assets.figures_max / tables_max
  4. IF 可新增:
     a. 用 Markdown 表格撰寫（文獻比較表、方法對照表等）
     b. 或 analysis_action(action="plot") / project_action(action="save_diagram")（如需圖形）
     c. 附 caption + 標記來源為 "agent-initiated"
     d. draft_action(action="insert_table") 或 draft_action(action="insert_figure") → 插入草稿
     e. 更新 asset_plan（追加到 plan.metadata.changelog）
     f. 記錄到 .audit/: 為何新增、依據哪些文獻
  5. IF 已達上限:
     → 評估是否替換低優先級 asset
     → 或以文字描述替代，不生成實際圖表

常見 Agent-Initiated Assets：
  - 「Table X. Comparison of [topic] across studies」 → 文獻整理表
  - 「Table X. Characteristics of included studies」 → SR/Review 常見
  - 「Figure X. Conceptual framework of [approach]」 → 架構圖

---

Phase 6: CROSS-SECTION CASCADING AUDIT

三階段審計：先全稿檢查 → 再回溯修正 → 最終驗證。

── Stage 1: 全稿掃描 ──
1. 🔔 HOOK C: post-manuscript (C1-C8, C9-C14)
2. 收集所有 issues → 分類為 CRITICAL / WARNING / INFO
3. 收集 Phase 5 FLAG（未解決的 Hook A/B issues）

── Stage 2: 分層回溯修正（Cascading Fix，最多 3 rounds）──
Round 1:
  FOR each CRITICAL issue:
    a. 定位到具體 section + 段落
    b. draft_action(action="patch") 修正
    c. re-run 該 section 的 Hook A（確認 patch 沒破壞原有品質）
  → re-run Hook C (C1-C8, C14 where strong claims changed)

Round 2 (IF still CRITICAL):
  FOR each remaining CRITICAL:
    a. 分析 Round 1 修正為什麼失敗
    b. 嘗試不同修正策略（重寫段落 vs 微調）
    c. draft_action(action="patch")
  → re-run Hook C

Round 3 (IF still CRITICAL):
  → LOG all remaining issues to .audit/quality-scorecard.md
  → 呈現給用戶，附具體修改建議
  → 等待用戶決定（修改 / 接受 / 回到 Phase 5 重寫）

── Stage 3: 最終驗證 ──
4. re-run Hook C → 確認 0 CRITICAL
5. 生成 quality-scorecard.md（量化分數）
6. 更新 checkpoint.json

Gate: 0 critical issues（warnings 記錄但可接受）

Cascading 回溯規則

Hook C Issue	回溯到	觸發的 Hook
C1 稿件不一致	較弱 section	Hook B4 → Hook A
C3 N 值跨 section 不一致	所有含 N 的 section	Hook A → patch
C4 縮寫未定義	首次出現的 section	Hook A4 → patch
C5 Wikilinks 不可解析	對應 section	Hook A2 → A4
C6 總字數超標	最長 section	Hook A1 → patch
C7a 圖表超限	—	合併或移至 supplementary
C7b 引用超限	—	標記低引用 refs → 用戶決定
C7c 字數精確比對	最長 section	Hook A1 → patch
C7d phantom 引用	對應 section	插入缺漏圖表或移除引用
C7e Wikilink 不一致	對應 section	Hook A4 → patch
C11 引用分布不均	缺引用的 section	Hook A2 → 補引用
C12 引用缺決策紀錄	—	生成 citation_decisions.json
C13 圖表順序/caption 問題	對應 section	Hook C7d → patch

---

Phase 6.5: EVOLUTION GATE（強制進入 Review）🆕

目的：建立 revision baseline，確保 Phase 7 Review 永遠執行（不因 Hook A-C 全過而跳過）。 觸發：Phase 6 完成後 MANDATORY（無跳過條件）。

── Step 1: Snapshot Baseline ──
1. DraftSnapshotManager.snapshot_all(reason="pre-review-baseline")
   → 快照所有 section 的當前版本
2. 記錄 quality-scorecard Round 0 分數
3. 記錄到 .audit/evolution-log.jsonl:
   {"event": "baseline", "round": 0, "timestamp": "...",
    "scorecard": {6 維度分數}, "word_count": N,
    "instruction_version": git_short_hash()}

── Step 2: Force Review Entry ──
4. 無論 Hook C 結果如何 → 設定 review_required = true
5. 載入 journal-profile.yaml → reviewer_perspectives + quality_threshold
6. IF journal-profile.yaml 不存在:
   → 從 templates/ 生成預設值 → 存入專案
   → LOG: "Auto-generated journal-profile.yaml with defaults"

Gate: baseline snapshot 完成 → pipeline_action(action="validate_phase", phase=65) 必須 PASS → 進入 Phase 7

---

Phase 7: AUTONOMOUS REVIEW（結構化 Review Loop — MANDATORY）🆕

目的：模擬同行審查，產出結構化 Review Report + Author Response，確保每個 issue 都被回應。 觸發：ALWAYS（Phase 6.5 強制進入，不可跳過）。即使 Hook A-C 全過、quality 已達標，仍必須至少執行 2 rounds（code-enforced min_rounds=2）。 上限：pipeline.review_max_rounds（預設 3）。 最低輪數：min_rounds=2（Code-Enforced：AutonomousAuditLoop._determine_verdict() 在 round < min_rounds 時強制返回 CONTINUE，不允許提前結束）。 Hard Gate：每輪 MUST call pipeline_action(action="start_review", min_rounds=2) 開始 + pipeline_action(action="submit_review", scores=...) 結束。Loop 結束後 pipeline_action(action="validate_phase", phase=7) 必須 PASS（驗證 rounds_completed >= min_rounds）。

Multi-Reviewer 設計（模擬 2-3 位獨立審稿人）🆕

人類同行審查通常由 2-3 位獨立審稿人進行，每位審稿人有不同的知識背景和思考模式。為模擬此過程：

每輪 Review 啟動 2-3 個 subagent，每個 subagent 使用不同的 top-tier 模型（避免思考模式雷同）：

Reviewer	模型	角色
R1	Claude Opus 4.6	Methodology Expert + Statistician
R2	OpenAI Codex 5.3	Domain Specialist + Editor
R3	Gemini Pro 3.1	Independent Critical Reviewer

每位 Reviewer 必須：

1. 搜尋文獻驗證：使用 unified_search / find_related_articles 搜尋相關文獻，比對稿件引用是否充分、結論是否與現有證據一致
2. 獨立閱讀全稿：不參考其他 Reviewer 的意見
3. 提出 5-10 個結構化問題：每個問題必須包含 section、paragraph、category、issue、suggestion
4. 文獻比對：至少引用 2-3 篇搜尋到的文獻來支持或挑戰稿件觀點
5. 給出獨立評分：6 個品質維度各自評分

合併流程：

• 所有 Reviewer 獨立完成後，合併為統一的 review-report-{round}.md
• 重複 issue 去重，保留最嚴格的 severity
• Author Response 必須回應所有 Reviewer 的所有 issue

載入 journal-profile.yaml → 取得 reviewer_perspectives + quality_threshold

── Review Loop（最少 min_rounds 輪，最多 max_rounds 輪）──

FOR round = 1 TO N:

  ── Stage A: Multi-Reviewer Review（獨立 subagent） ──
  LAUNCH 2-3 subagents in parallel (each using different model):

  FOR each reviewer subagent:
    1. 搜尋文獻：unified_search() 搜尋與稿件主題相關的最新文獻（至少 5 篇）
    2. 比對文獻：find_related_articles() / find_citing_articles() 驗證稿件引用
    3. 獨立審查全稿，提出 5-10 個結構化問題
    4. 以搜尋到的文獻為依據，標記稿件中的不足或錯誤
    5. 獨立評分（6 維度）

    Reviewer 角色覆蓋：
    "methodology_expert":
      - 研究設計是否嚴謹？統計方法是否恰當？
      - 方法是否可再現？偏差控制是否充分？
      - 搜尋同類方法學文獻 → 比對是否有遺漏的 best practice

    "domain_specialist":
      - 文獻引用是否全面且最新？
      - 對領域 gap 的理解是否準確？臨床意義是否明確？
      - 搜尋最新系統性回顧 → 驗證稿件是否與當前共識一致

    "statistician":
      - 統計假設是否合理？結果呈現是否清晰？
      - 圖表是否有效傳達數據？
      - 搜尋統計方法指引 → 驗證分析方法的恰當性

    "editor":
      - 寫作品質（清晰度、邏輯流、語法）
      - 是否符合期刊風格？圖表品質與必要性

  MERGE all reviewer outputs → 統一 review-report-{round}.md

  產出 .audit/review-report-{round}.md：
  ┌─────────────────────────────────────────────────┐
  │ ---                                             │
  │ round: 1                                        │
  │ date: "YYYY-MM-DD"                              │
  │ reviewers:                                      │
  │   - role: "Methodology Expert"                  │
  │     issues_major: 2                             │
  │     issues_minor: 1                             │
  │   - role: "Domain Specialist"                   │
  │     issues_major: 1                             │
  │     issues_minor: 3                             │
  │ total:                                          │
  │   major: 3                                      │
  │   minor: 5                                      │
  │   optional: 2                                   │
  │ ---                                             │
  │                                                 │
  │ # Review Report — Round {round}                 │
  │                                                 │
  │ ## Reviewer 1: Methodology Expert               │
  │ ### MAJOR                                       │
  │ - id: R1-M1                                     │
  │   section: Methods                              │
  │   paragraph: methods-p3                         │
  │   category: methodology                         │
  │   issue: 缺少 sample size justification         │
  │   suggestion: 加入 power analysis               │
  │ ### MINOR                                       │
  │ - id: R1-m1                                     │
  │   section: Results                              │
  │   ...                                           │
  └─────────────────────────────────────────────────┘

  ── Stage B: Author Response（全 issue 須回應） ──
  產出 .audit/author-response-{round}.md：
  ┌─────────────────────────────────────────────────┐
  │ ---                                             │
  │ round: 1                                        │
  │ response_to: "review-report-1.md"               │
  │ actions:                                        │
  │   accepted: 6                                   │
  │   accepted_modified: 2                          │
  │   declined: 2                                   │
  │ ---                                             │
  │                                                 │
  │ # Author Response — Round {round}               │
  │                                                 │
  │ ### R1-M1: Sample size justification            │
  │ - **Action**: ACCEPT                            │
  │ - **Response**: Added power analysis...         │
  │ - **Change**: methods-p3 (+45 words)            │
  │ - **Verified**: Hook A re-run ✅               │
  │                                                 │
  │ ## Completeness Check                           │
  │ | Issue ID | Addressed | Action      |          │
  │ | R1-M1    | ✅       | ACCEPT      |          │
  │ | R2-o1    | ✅       | DECLINE     |          │
  │ ALL issues addressed: ✅                        │
  └─────────────────────────────────────────────────┘

  ── Completeness Check（每輪必過）──
  FOR issue IN review_report.all_issues:
    IF issue.id NOT IN author_response → FAIL（禁止忽略 issue）
  → 未回應的 issue 必須標記 DECLINE + 理由

  ── Stage C: 執行修正（MANDATORY — 稿件必須被修改） ──
  ⚠️ HARD ENFORCEMENT: `pipeline_action(action="submit_review", ...)` 會比對稿件 hash。
  若稿件未修改 → 提交會被 REJECT。

  FOR each ACCEPTED issue:
    1. 定位 paragraph ID（from manuscript-plan.yaml）
    2. draft_action(action="patch") 修正
    3. re-run Hook A on patched section
    4. 記錄到 author-response

  FOR each MINOR ACCEPTED issue:
    1. batch draft_action(action="patch") 修正
    2. 快速 Hook A 驗證

  OPTIONAL + DECLINED issues → LOG only（不自動修正）

  ── Stage C2: 敘事強化（MANDATORY — 即使無結構問題） ──
  人類 reviewer 即使不要求結構修改，也會提升敘事品質。
  AI reviewer 必須做到至少同等標準：
    1. 選擇至少 3 段落進行「敘事強化」（tighten prose, improve transitions,
       strengthen claims, eliminate redundancy, improve word economy）
    2. 每段 draft_action(action="patch") 修正，附帶改善理由
    3. 記錄到 author-response 的 "Narrative Enhancements" section

  IF 沒有結構性 issue（全部 DECLINE 或 OPTIONAL only）：
    → Stage C2 仍然 MANDATORY（最低改 3 段落）
    → 目標：人類讀者應能看到「review 前」vs「review 後」有明顯差異

  ── Stage C3: Anti-AI 自然度審查（MANDATORY — Code-Enforced Gate） ──
  AI 生成文字常被偵測器（Gemini 3.1 等）秒辨。Stage C3 強制 Agent 自我檢測並修正。
  更關鍵的是：有經驗的人類審稿人會注意到段落間的「語體斷裂」——前段 ESL 風格突然切換到
  流暢的 corporate-academic prose，即使通過自動偵測也會引起懷疑。

  Step 1: Code-Enforced Hook Gate（三層掃描）
    → run_quality_checks(action="writing_hooks", hooks="A3,A3B,A3C")
    → A3: 禁止詞掃描（~150 個 AI 特徵用語）
    → A3b: 結構信號偵測（句長均勻度、轉折詞密度、句首多樣性、三連列舉、段落均勻度）
    → A3c: 語體一致性偵測（段落級可讀性指標 z-score 異常偵測 + 詞彙精緻度落差）
    → 任何 CRITICAL → 必須 draft_action(action="patch") 修正後重跑，直到 PASS

  Step 2: Agent 自我審閱（Anti-AI Naturalness Check）
    Agent 以下列視角重新閱讀全文：
    a) 是否有「四平八穩」的語調？（每段都同一節奏 → 改）
    b) 是否過度使用被動語態或名詞化？（nominalization → 改為動詞）
    c) 是否有 AI 特有的「禮貌性冗餘」？（"It is important to note that" → 刪）
    d) 段落是否缺乏個人學術觀點？（全是 hedging → 加 assertive claim）
    e) 是否有「假平衡」？（on the one hand... on the other hand → 取立場）
    f) **語體斷裂**：A3c 標記的 outlier 段落是否「太流暢」而脫離作者自然語體？
       → 降級過度精煉的句子、加回作者的「笨拙但真實」語法特徵
    → 每項至少修正 2 處 → draft_action(action="patch")

  Step 3: 雙 Subagent 交叉審計（RECOMMENDED — 至少最終輪必做）
    使用兩個不同模型的 subagent 分別審計，交叉比對結果：

    Subagent 1 — Surface Scanner（concept-challenger 或主 Agent）：
      → 審計目標：黑名單詞、結構信號、自動偵測器可偵測的 pattern
      → 問題：「能否通過 GPTZero？哪些具體詞/句需要替換？」

    Subagent 2 — Voice Analyst（domain-reviewer）：
      → 審計目標：語體一致性、ESL baseline vs polished prose 對比
      → 問題：「人類審稿人會不會因為語體突變而起疑？逐段評分 1-5」
      → 重點：段落級 AI 機率評分，標出 TOP 5 最可疑句子

    交叉比對規則：
      → 兩者都標 🔴 → 必須重寫該段落
      → 僅一方標 ⚠️ → Agent 判斷是否需要調整
      → 兩者都 ✅ → 安全

  Step 4: 修正後驗證
    → 重跑 run_quality_checks(action="writing_hooks", hooks="A3,A3B,A3C")
    → 必須全部 PASS 或僅 WARNING（無 CRITICAL）才能進入 Stage D
    → IF 仍有 CRITICAL → 回到 Step 2 再修，最多 3 輪

  ── Stage D: 品質重評 ──
  更新 quality-scorecard.md：
    | 維度 | Round N-1 分數 | Round N 分數 | 變化 |

  計算總分 → 比對 quality_threshold

  IF 總分 ≥ quality_threshold:
    → ✅ PASS: 結束 review loop
    → LOG: "Review completed at round {round}, score={score}"

  IF 總分 < quality_threshold AND round < N:
    → 繼續下一輪（重新審稿）
    → 分析哪些維度分數最低 → 下一輪重點關注

  IF round = N AND 總分 < quality_threshold:
    → ⚠️ PARTIAL: 呈現剩餘問題 + 分數趨勢
    → 詢問用戶：
      a) 接受當前品質（記錄風險）
      b) 繼續 N 輪（用戶延長 loop）
      c) 手動修改後重新 review
      d) 🔁 回退到 Phase 5 重寫特定 section → call `pipeline_action(action="rewrite_section", ...)`

  ── Stage D2: 回退決策（Agent 自主判斷 + 自主執行） ──
  IF Agent 判斷某些 section 的問題無法透過 draft_action(action="patch") 修正，需要整個 section 重寫：
    1. 識別需要重寫的 section（通常是 persistent critical issues 集中的 section）
    2. **Autopilot 模式**（預設）：
      → Agent 直接呼叫 `pipeline_action(action="rewrite_section", sections="Methods,Results", reason="...")`
       → 決策和理由記入 `.audit/pipeline-run-{ts}.md`
       → Pipeline 回退到 Phase 5 → 僅重寫指定 sections
    3. **手動模式**（`autopilot: false` 或 `autopilot_pause_at` 含 `"phase7_rewrite"`）：
       → 🗣️ 詢問用戶確認：「建議重寫 [section]，是否同意？」
      → 用戶確認後執行 `pipeline_action(action="rewrite_section", ...)`
    4. 重寫後走 Phase 5 → 6 → 7 完整流程
    5. ⚠️ regression_count > 2 → **安全閥：強制停下詢問用戶**（防止無限循環）

  ── Stage E: Evolution Tracing（每輪結束後） ──
  追加到 .audit/evolution-log.jsonl：
  {"event": "review_round", "round": N,
   "timestamp": "...",
   "scorecard": {6 維度分數},
   "scorecard_delta": {與 Round N-1 的差異},
   "review_issues": {"major": M, "minor": m, "accepted": A, "declined": D},
   "draft_snapshots": ["snapshot_path_1", ...],
   "patches_applied": [{"section": "...", "issue_id": "R1-M1", "words_changed": N}],
   "instruction_version": git_short_hash()}

Hook E: EQUATOR Reporting Guidelines Compliance（Phase 7 Stage A 附加）🆕

Phase 7 的每輪 Review 中，額外執行 EQUATOR 報告指引合規檢查。這是系統的核心賣點之一：AI 能逐條、不遺漏地執行人類 reviewer 經常忽略的 checklist 項目。

觸發：Phase 7 每輪 Review 的 Stage A（與 4 角色審查並行）

E1: 自動偵測適用指引

1. 讀取 journal-profile.yaml → reporting_guidelines.checklist
2. IF checklist 已指定 → 使用指定指引
3. IF checklist 為空 → 依據 paper.type + Methods 內容自動偵測：

   paper.type × 內容特徵 → 適用指引：
   ┌─────────────────────────┬───────────────────────────────────┐
   │ Paper Type / 特徵       │ 主要指引          │ AI 擴展指引   │
   ├─────────────────────────┼───────────────────────────────────┤
   │ RCT                     │ CONSORT 2010      │ CONSORT-AI    │
   │ RCT + AI intervention   │ CONSORT-AI        │ SPIRIT-AI     │
   │ Observational cohort    │ STROBE            │ RECORD        │
   │ Observational + routine │ RECORD            │ STROBE        │
   │ Systematic review       │ PRISMA 2020       │ PRISMA-S      │
   │ Meta-analysis           │ PRISMA 2020       │ MOOSE         │
   │ MA of observational     │ MOOSE             │ PRISMA 2020   │
   │ Diagnostic accuracy     │ STARD 2015        │ STARD-AI      │
   │ Diagnostic + AI         │ STARD-AI          │ CLAIM         │
   │ Prediction model        │ TRIPOD 2015       │ PROBAST       │
   │ Prediction + AI/ML      │ TRIPOD+AI         │ MI-CLAIM      │
   │ AI clinical decision    │ DECIDE-AI         │ TRIPOD+AI     │
   │ AI clinical trial       │ SPIRIT-AI         │ CONSORT-AI    │
   │ Medical imaging AI      │ CLAIM             │ STARD-AI      │
   │ Case report             │ CARE 2013         │ —             │
   │ Qualitative research    │ SRQR / COREQ      │ —             │
   │ Quality improvement     │ SQUIRE 2.0        │ —             │
   │ Economic evaluation     │ CHEERS 2022       │ —             │
   │ Animal research         │ ARRIVE 2.0        │ —             │
   │ Protocol (trial)        │ SPIRIT 2013       │ SPIRIT-AI     │
   │ Protocol (SR)           │ PRISMA-P 2015     │ —             │
   │ Software/Methods paper  │ —                 │ see Note      │
   └─────────────────────────┴───────────────────────────────────┘

   Note: Software/Methods papers 無專屬 EQUATOR 指引，
         但若涉及 AI/ML → 適用 TRIPOD+AI 相關項目（選擇性）

E2: Checklist 逐條驗證

FOR guideline IN detected_guidelines:
  checklist = load_checklist(guideline)  # 內建 checklist 資料庫

  FOR item IN checklist.items:
    # 定位：該項目應出現在哪個 section
    target_section = item.expected_section  # e.g. "Methods", "Results"
    content = draft_action(action="read", filename=target_section)

    # 三級判定
    IF item clearly addressed in content:
      → ✅ REPORTED (記錄: section + paragraph + 摘要)
    ELIF item partially addressed:
      → ⚠️ PARTIAL (記錄: 缺什麼、建議補充)
    ELSE:
      → ❌ NOT REPORTED (記錄: 建議加入的位置和內容)

  # 合規率計算
  compliance_rate = REPORTED / total_applicable_items
  partial_rate = PARTIAL / total_applicable_items

  # 閾值判定（依 item 重要性分級）
  IF any ESSENTIAL item is NOT REPORTED → MAJOR issue
  IF compliance_rate < 80% → WARNING
  IF compliance_rate ≥ 80% AND all ESSENTIAL reported → PASS

E3: EQUATOR 指引內建資料庫

指引	全稱	適用範圍	項目數	來源
CONSORT 2010	Consolidated Standards of Reporting Trials	RCT	25 項	equator-network.org
CONSORT-AI	CONSORT Extension for AI	AI 介入的 RCT	14 擴展項	Lancet Digital Health 2020
STROBE	Strengthening Reporting of Observational Studies	觀察性研究	22 項	equator-network.org
PRISMA 2020	Preferred Reporting Items for SR and MA	系統性回顧	27 項	BMJ 2021
PRISMA-S	PRISMA Search Extension	搜尋策略報告	16 項	Systematic Reviews 2021
PRISMA-P	PRISMA for Protocols	SR 計畫書	17 項	BMJ 2015
MOOSE	Meta-analysis of Observational Studies	觀察性研究 MA	35 項	JAMA 2000
STARD 2015	Standards for Reporting Diagnostic Accuracy	診斷準確度	30 項	BMJ 2015
STARD-AI	STARD for AI Diagnostic	AI 診斷研究	擴展項	Nature Medicine 2021
TRIPOD 2015	Transparent Reporting of Prediction Models	預測模型	22 項	BMJ 2015
TRIPOD+AI	TRIPOD for AI/ML Prediction	AI/ML 預測模型	27+擴展	BMJ 2024
PROBAST	Prediction Model Risk of Bias Assessment	預測模型偏差	20 項	Annals Int Med 2019
DECIDE-AI	AI Decision Support Early Evaluation	AI 決策支援	17 項	Nature Medicine 2022
SPIRIT 2013	Standard Protocol Items for Trials	試驗計畫書	33 項	equator-network.org
SPIRIT-AI

E4: Compliance Report 產出

每輪 Review 產出 .audit/equator-compliance-{round}.md：

# EQUATOR Compliance Report — Round {round}

## Detected Guidelines: TRIPOD+AI (primary), MI-CLAIM (secondary)

## Detection Basis: paper.type=prediction-model, Methods mentions "deep learning"

### TRIPOD+AI Compliance: 85% (23/27 items)

| #   | Item                                 | Section      | Status          | Notes            |
| --- | ------------------------------------ | ------------ | --------------- | ---------------- |
| 1   | Title identifies as prediction model | Title        | ✅ REPORTED     |                  |
| 2   | Abstract: structured summary         | Abstract     | ✅ REPORTED     |                  |
| 3a  | Background and objectives            | Introduction | ✅ REPORTED     |                  |
| 4a  | Source of data                       | Methods      | ✅ REPORTED     |                  |
| 4b  | Data collection dates                | Methods      | ⚠️ PARTIAL      | Missing end date |
| ... |                                      |              |                 |                  |
| 10d | Handling of missing data             | Methods      | ❌ NOT REPORTED | → Add to Methods |
| 15a | Model performance metrics            | Results      | ✅ REPORTED     |                  |

### MI-CLAIM Compliance: 73% (11/15 items)

...

### Summary

| Guideline | Compliance | ESSENTIAL items | Status                 |
| --------- | ---------- | --------------- | ---------------------- |
| TRIPOD+AI | 85%        | 20/22 ✅        | ⚠️ 2 ESSENTIAL missing |
| MI-CLAIM  | 73%        | 9/10 ✅         | ⚠️ 1 ESSENTIAL missing |

### Action Items (for Author Response)

- [E-M1] TRIPOD+AI Item 10d: Add missing data handling to Methods
- [E-M2] TRIPOD+AI Item 4b: Add data collection end date
- [E-m1] MI-CLAIM Item 12: Add model interpretability discussion

E5: Integration with Phase 7 Review Loop

Phase 7, Stage A（每輪）:
  1. 執行 4 角色 Reviewer 審查 → review-report-{round}.md
  2. 執行 Hook E → equator-compliance-{round}.md
  3. 合併 issues: Review issues + EQUATOR issues → 統一編號
     - Review issues: R1-M1, R2-m1, ...
     - EQUATOR issues: E-M1, E-m1, ... (E = EQUATOR)
  4. Author Response 必須回應兩種 issue

Phase 7, Stage D（品質重評）:
  quality-scorecard 新增維度：
  | 維度 | 評分標準 | 權重 |
  | EQUATOR 合規 | checklist compliance rate + ESSENTIAL 完整度 | 15% |
  → 原有 6 維度權重等比調降，總和仍 = 100%

Review 品質維度（quality-scorecard）

維度	評分標準 (0-10)	權重
引用品質	引用充分、最新、高影響力、格式正確	10%
方法學再現性	研究設計、統計、可再現	18%
文字品質	清晰度、邏輯流、無 AI 痕跡、語法	16%
概念一致性	NOVELTY 體現、SELLING POINTS、全稿一致	16%
格式合規	字數、圖表、引用數、期刊要求	7%
圖表品質	圖表必要性、清晰度、caption、數據呈現	8%
EQUATOR 合規	checklist compliance + ESSENTIAL 項完整	13%
再現性/資料可用	資料分享聲明、程式碼公開、protocol 註冊	12%

總分 = Σ(維度分數 × 權重)

Review vs Hook 的分工

面向	Hook A-C（Phase 5-6）	Autonomous Review（Phase 7）
目的	技術合規	學術品質 + 報告指引合規
觸發時機	寫作過程中 / 全稿完成後	Phase 6.5 強制進入（MANDATORY）
關注點	格式、引用、字數、一致性	內容品質、邏輯、學術說服力 + EQUATOR
修正方式	draft_action(action="patch")（局部修正）	可能 rewrite 段落或重組論證
角色	自動化 linter	模擬 Reviewer + EQUATOR compliance
停止條件	0 CRITICAL	quality_threshold 達標 + ESSENTIAL 完整
產出	audit log	review-report + equator-compliance
粒度	pass/fail	MAJOR/MINOR/OPTIONAL + checklist 逐條

---

Phase 8: REFERENCE SYNC

1. draft_action(action="sync_references", filename="manuscript.md") → 生成 References section
2. 確認所有 [[wikilinks]] 已解析
3. format_references(style=journal-profile.references.style)
4. 驗證引用數量 ≤ references.reference_limits[paper.type]（fallback max_references）
5. IF 超過上限 → 標記最少被引用的 refs → 建議刪除

Gate: 0 broken links + 引用數量合規

---

Phase 9: EXPORT（Code-Enforced — CRITICAL Gate）

Skill: word-export

⚠️ Code-Enforced: pipeline_action(action="validate_phase", phase=9) 對 docx 和 pdf 的檢查為 CRITICAL severity。必須同時產出 docx 和 pdf，否則 Gate 不會通過。

Facade 入口仍是 export_document(action="docx") / export_document(action="pdf")；正式呼叫時必填 draft_filename 與 output_filename。

1. export_document(action="docx", draft_filename="manuscript.md", output_filename="paper.docx") → 產出 DOCX
2. export_document(action="pdf", draft_filename="manuscript.md", output_filename="paper.pdf") → 產出 PDF
3. inspect_export(action="list_templates") → 選擇 template（優先匹配 journal-profile.journal.name）
4. export_document(action="session_start") → export_document(action="session_insert") × N
5. 驗證必要文件清單（from required_documents.*）：
   • cover_letter → 如尚未產生，提示用戶或自動草擬
   • author_contributions → 提示用戶填寫
   • ethics_statement → 提示用戶提供
6. inspect_export(action="verify_document") → export_document(action="session_save")
7. inspect_export(action="docx_smoke") 或 inspect_export(action="xml_smoke") → 驗證 DOCX zip/XML 結構、word/document.xml、段落與可見文字

Gate: pipeline_action(action="validate_phase", phase=9) — docx + pdf 必須存在（CRITICAL）+ 必要文件清單完成；DOCX XML smoke 應 PASS 才進入最終交付

---

Phase 9 advisory task: SUBMISSION READINESS

輸入: Phase 9 匯出的文件 外部 MCP: —

目的：投稿前的最終系統性檢查，確保所有投稿要件齊全。

1. 檔案清單核對（依期刊 profile）：

   • Title page（含 author info、ORCID、corresponding author）
   • Manuscript（blinded if required）
   • Abstract（structured / unstructured）
   • Cover letter
   • Conflict of interest declarations
   • Funding statement
   • Ethics approval statement
   • Data availability statement
   • Supplementary files（if any）
   • Figure files（high-res, correct format）
   • Table files（if separate）
   • EQUATOR checklist（if required）
   • Author contributions (CRediT if applicable)

2. 格式最終確認：

   • 字數限制（abstract + main text）
   • 圖表數量限制
   • Reference 格式（期刊 CSL style）
   • 檔案命名慣例

3. 內容一致性：

   • Title page 作者 == manuscript 作者
   • Abstract numbers == main text numbers
   • Cover letter 提及正確期刊名

4. 產出 exports/submission-checklist.md（✅/❌ 清單）

Gate: submission-checklist.md 全部 ✅ 或用戶確認接受列外

---

Phase 10: RETROSPECTIVE（閉環核心）

🔔 HOOK D: meta-learning（見下方定義，含 D7 Review Retrospective、D8 EQUATOR Retrospective）

1. 回顧執行紀錄 + Hook 觸發統計 + Review 輪次統計
2. 更新 SKILL.md Lessons Learned
3. 更新 AGENTS.md（如適用）
4. 更新 .memory/ 完整紀錄
5. 分析 journal-profile 設定是否合理 → 建議微調
6. 🆕 D7: 分析 review-report + author-response → 演化 Reviewer 指令
7. 🆕 D8: 分析 equator-compliance → 演化 EQUATOR 偵測與分類邏輯

---

Phase 11: FINAL DELIVERY（Code-Enforced — CRITICAL Gate）🆕

目的：確認 paper 交付物完整可審計。Git 僅作為 optional provenance，不可阻擋 paper-only workflow。 觸發：Phase 10 完成後自動進入。

⚠️ Code-Enforced: pipeline_action(action="validate_phase", phase=11) 驗證以下 CRITICAL 項目：

• Phase 9 匯出的 .docx + .pdf 存在
• Phase 10 retrospective / meta-learning artifacts 完整
• Phase 7 review loop 已完成

以下項目為 optional provenance / WARNING or INFO，不得阻擋 final delivery：

• Git repository 是否存在
• 工作目錄是否乾淨
• 最新 commit 是否包含專案檔案
• 是否有 remote/upstream / 是否 push

流程：

1. 確認 Phase 9 .docx + .pdf 已產出
2. 確認 Phase 10 .audit/pipeline-run-*.md、.audit/meta-learning-audit.yaml、.audit/meta-learning-feedback.yaml 完整
3. pipeline_action(action="validate_phase", phase=11, response_format="json", compact=true) → 驗證 PASS
4. 若專案使用 Git，可選擇 commit/push 作為 provenance；若用戶只是寫 paper，不需要 remote

Gate: pipeline_action(action="validate_phase", phase=11) — final paper delivery artifacts complete；Git remote/push 不作為硬性條件

---

Audit Trail 生成（每個 Phase 完成時自動執行）

Agent 必須在 projects/{slug}/.audit/ 維護以下檔案：

增量更新（每個 Phase 結束時）

Phase 完成 → 更新以下檔案：

1. pipeline-run-{YYYYMMDD-HHmm}.md（增量 append）
   格式：
   ## Phase {N}: {名稱}
   - 開始時間 / 結束時間
   - 輸入：{files read}
   - 輸出：{files written}
   - Hook 結果：
     | Hook | 觸發 | 通過 | 修正次數 | 最終結果 |
   - 決策紀錄：{任何自動決策 + 理由}
   - Issues flagged for later: {list}

2. checkpoint.json（覆寫更新）
   {
     "last_completed_phase": N,
     "current_section": "Methods",
     "phase_outputs": { "P1": "project_created", "P2": "15_refs_saved", ... },
     "flagged_issues": [...],
     "audit_stats": { "hook_a_triggers": 5, "hook_a_passes": 3, ... },
     "timestamp": "ISO-8601"
   }

Phase 6 完成後生成

3. quality-scorecard.md
   | 維度 | 分數 (0-10) | 說明 |
   | 引用品質 | | |
   | 方法學再現性 | | |
   | 文字品質 | | |
   | 概念一致性 | | |
   | 格式合規 | | |
   | 圖表品質 | | |
   | 總分 | | |

4. hook-effectiveness.md
   | Hook | 觸發次數 | 通過次數 | 修正次數 | 誤報次數 | 有效率 |
   → 供 Hook D 分析用

Phase 7 每輪生成

5. review-round-{N}.md
   ## Round {N} Summary
   | 角色 | MAJOR issues | MINOR issues | OPTIONAL |
   | Issue | 角色 | 嚴重度 | 修正策略 | 修正後狀態 |

   ## Quality Score Trend
   | 維度 | Round 0 | Round 1 | Round 2 | ... | 變化趨勢 |
   | 總分 | 6.2 | 7.1 | 7.8 | ... | ↑ |

6. equator-compliance-{N}.md  🆕
   ## EQUATOR Compliance Report — Round {N}
   ## Detected Guidelines: {auto-detected or specified}
   | # | Item | Section | Status | Notes |
   → 見 Hook E4 格式定義

Evolution Tracing（Phase 6.5 → 7 → 10）🆕

7. evolution-log.jsonl（append-only，每事件一行 JSON）

   ## 事件類型：
   - baseline: Phase 6.5 建立的基線快照
   - review_round: Phase 7 每輪 review 結果
   - equator_check: Hook E 每輪 compliance 結果
   - hook_correction: Hook A-C 修正事件
   - meta_learning: Phase 10 自我改進事件

   ## Schema:
   {"event": "baseline", "round": 0, "timestamp": "ISO-8601",
    "scorecard": {"citation": 7, "methodology": 8, "text": 6, ...},
    "word_count": 3200,
    "instruction_version": "abc1234"}

   {"event": "review_round", "round": 1, "timestamp": "...",
    "scorecard": {"citation": 7.5, "methodology": 8, "text": 7, ...},
    "scorecard_delta": {"text": +1, "total": +0.8},
    "review_issues": {"major": 3, "minor": 5, "accepted": 7, "declined": 1},
    "patches_applied": [{"section": "Methods", "issue_id": "R1-M1", "words_changed": 45}],
    "instruction_version": "abc1234"}

   {"event": "equator_check", "round": 1, "timestamp": "...",
    "guideline": "TRIPOD+AI", "compliance_rate": 0.85,
    "essential_complete": false, "missing_essential": ["Item 10d", "Item 4b"],
    "action_items": 3}

   {"event": "meta_learning", "phase": 10, "timestamp": "...",
    "skill_updates": ["Lessons Learned +1"],
    "hook_adjustments": [{"hook": "B5", "param": "threshold", "old": 5, "new": 6}],
    "total_rounds": 2, "final_score": 7.8}

   ## 用途：
   - Phase 10 D1-D9 分析 → 產出 evolution summary
   - 跨 run 比較（如有多次執行）
   - 論文自身的 Fig 1 / Table 2（框架效果量化證據）

Phase 2 完成後生成

5. search-strategy.md
   - 搜尋策略 + MeSH terms
   - 每組搜尋的結果數量
   - 篩選標準 + 排除原因

6. reference-selection.md
   - 最終選擇的文獻列表 + 選擇理由
   - 排除的重要文獻 + 排除原因

Phase 3 完成後生成

7. concept-validation.md
   - 驗證分數 (每輪)
   - 修正歷史
   - CGU 使用紀錄（如有）

---

Checkpoint 恢復機制

實作：CheckpointManager（infrastructure/persistence/checkpoint_manager.py）

Pipeline 啟動時：
1. 檢查 projects/{slug}/.audit/checkpoint.json
2. IF exists:
   → ckpt = CheckpointManager(audit_dir)
   → summary = ckpt.get_recovery_summary()  # 顯示上次進度
   → 詢問：
     a) 從 Phase {N+1} 繼續
     b) 從當前 section 繼續
     c) 重新開始（保留文獻和 concept）
     d) 完全重來 → ckpt.clear()
3. IF 選擇繼續：
   → state = ckpt.load()
   → 載入 phase_outputs
   → 載入 flagged_issues（帶入 Phase 6）
   → 跳到對應 Phase/Section

Phase 轉換時：
  ckpt.save_phase_start(phase, name)
  ... 執行 ...
  ckpt.save_phase_completion(phase, name, outputs, flagged_issues)

---

Copilot Hooks 定義（寫作時觸發）

Hook A: post-write（每次寫完立即，最多 N rounds，N = pipeline.hook_a_max_rounds）

#	檢查項	MCP Tool	失敗行為	閾值來源
A1	字數在 target ±20%	draft_action(action="count_words")	draft_action(action="patch") 精簡/擴充	paper.sections[].word_limit
A2	引用密度達標	draft_action(action="available_citations")	suggest_citations + draft_action(action="patch")	pipeline.writing.citation_density.*
A3	無 Anti-AI 模式	run_quality_checks(action="writing_hooks", hooks="A3")	draft_action(action="patch") 改寫	pipeline.writing.anti_ai_strictness
A3b	AI 結構信號偵測 🆕	run_quality_checks(action="writing_hooks", hooks="A3B")	draft_action(action="patch") 改寫	Code-Enforced（5 項結構分析）
A3c	語音一致性偵測 🆕	run_quality_checks(action="writing_hooks", hooks="A3C")	draft_action(action="patch") 改寫	Code-Enforced（z-score 離群值）
A4	Wikilink 格式正確	validate_wikilinks	自動修復	—
A5	語言一致性（BrE/AmE）	run_quality_checks(action="writing_hooks", hooks="A5")	draft_action(action="patch") 統一拼法	pipeline.writing.prefer_language
A6	段落重複偵測	run_quality_checks(action="writing_hooks", hooks="A6")	draft_action(action="patch") 改寫重複段	pipeline.writing.overlap_threshold
A7	文獻數量充足性 🆕	run_quality_checks(action="writing_hooks", hooks="A7")	BLOCK 寫作，提示擴大搜尋	DEFAULT_MINIMUM_REFERENCES per type

Hook A Cascading Protocol

Round 1: 執行 A1-A4 → 收集所有 issues
  → IF issues:
    → batch draft_action(action="patch")（一次修正多個問題）
    → 記錄：哪些問題、修正策略

Round 2: re-run A1-A4
  → IF same issues persist:
    → 改變策略（例：A1 字數超標 → Round 1 精簡句子 → Round 2 刪除次要段落）
    → draft_action(action="patch")
    → 記錄：策略變更原因

Round 3: re-run A1-A4
  → IF still issues:
    → LOG to audit trail（不阻擋）
    → FLAG issue type + section → 帶入 Phase 6 Cascading Audit
    → 繼續下一步（Hook B）

每 round 的修正策略升級：
  A1 字數: trim sentences → remove paragraphs → restructure section
  A2 引用: suggest_citations → search more refs → flag for user
  A3 Anti-AI: rephrase → rewrite paragraph → flag specific phrases
  A3b AI結構信號: 句長CV/轉折詞密度/句首多樣性/三連列舉/段落CV → draft_action(action="patch")
  A3c 語音一致性: 段落風格離群值 → draft_action(action="patch") 改寫風格斷裂段落
  A4 Wikilink: auto-fix → manual check → flag broken refs

A2 引用密度標準：Introduction ≥1/100w, Methods ≥0, Results ≥0, Discussion ≥1/150w

A3 Anti-AI 禁止詞（~75 個）：涵蓋 Classic AI filler、Grandiose/buzzword、Metaphorical cliché、Vague academic padding、Formulaic conclusion/transition、AI-specific phrasing 六大類。常見如 In recent years, plays a crucial role, has garnered significant attention, a comprehensive understanding, This groundbreaking → 替換為具體內容。

A3b AI 結構信號偵測（Code-Enforced）：

• 句長均勻度: CV < 0.25 = WARNING（AI 傾向產出等長句子）
• 轉折詞密度: 句首轉折詞 >20% WARNING, >35% CRITICAL
• 句首多樣性: unique ratio < 0.50 = WARNING
• 三連列舉: X, Y, and Z 出現 >3 次 = WARNING
• 段落長度均勻度: CV < 0.20 = WARNING

A3c 語音一致性偵測（Code-Enforced）：

• 段落級特徵：avg_sent_len、avg_word_len、type_token_ratio、punct_complexity
• 文件基線：計算全文各指標的 mean + std
• 離群偵測：任一指標 z-score > 1.8 → WARNING（風格斷裂）
• 詞彙精緻度落差：max − min avg_word_len > 1.2 → WARNING（ESL vs 精修段落）
• 典型場景：ESL 文法段落突然轉為精修企業學術文風 → 人類審稿者可察覺

---

Hook B: post-section（section 完成後，含回溯修正）

#	檢查項	MCP Tool	失敗行為
B1	與 concept.md 一致	draft_action(action="read", filename="concept.md") + Agent 比對	重寫不一致段落
B2	🔒 NOVELTY 在 Intro 體現	draft_action(action="read") 檢查	draft_action(action="patch") 加入
B3	🔒 SELLING POINTS 在 Discussion	逐條比對	draft_action(action="patch") 補充
B4	與已寫 sections 不矛盾	draft_action(action="read") 交叉比對	修正矛盾處
B5	方法學可再現性	Agent 依 paper_type 評估	draft_action(action="patch") 補細節
B6	寫作順序驗證	check_writing_order	⚠️ Advisory（不阻擋）
B7	Section Brief 合規 🆕	Agent 比對 manuscript-plan.yaml	draft_action(action="patch") 補遺漏

Hook B Cascading Protocol

執行 B1-B7 → 分類 issues:
  CRITICAL: B1 concept 不一致, B2 🔒 NOVELTY 缺失, B5 方法學 <5 分
  WARNING:  B3 selling points 不完整, B4 sections 矛盾, B7a/b/d/e Brief 遺漏
  ADVISORY: B6 寫作順序, B7c 段落順序偏離

IF CRITICAL issues:
  → 針對性 draft_action(action="patch") 修正
  → re-run Hook A on patched areas（1 round，確認 patch 沒破壞品質）
  → re-run 失敗的 Hook B checks
  → IF still CRITICAL after 2 attempts:
    → FLAG for Phase 6 Cascading Audit
    → 記錄到 .audit/pipeline-run-{ts}.md

IF WARNING issues:
  → draft_action(action="patch") 修正（1 round）
  → IF still WARNING → LOG + continue（Phase 6 會再檢查）

IF ADVISORY only:
  → LOG to audit trail → continue

B5 方法學 Checklist

基礎方法學檢查（所有 paper type）：

檢查項	Original	Case	Systematic	AI/ML Prediction	AI Clinical
研究設計描述	✅	✅	✅	✅	✅
主要/次要結局	✅	⬜	✅	✅	✅
樣本量/power	✅	⬜	⬜	✅	✅
納入/排除標準	✅	⬜	✅	✅	✅
統計方法匹配	✅	⬜	✅	✅	✅
變項定義	✅	✅	⬜	✅	✅
倫理聲明	✅	✅	⬜	✅	✅
收集期間	✅	✅	✅	✅	✅
EQUATOR	CONSORT/STROBE	CARE	PRISMA	TRIPOD+AI	DECIDE-AI

AI/ML 特定檢查項（僅 AI/ML paper types）：

檢查項	Prediction	Diagnostic	Imaging	Decision
Data split 策略	✅	✅	✅	✅
模型架構/超參數	✅	✅	✅	✅
訓練/驗證/測試集比例	✅	✅	✅	⬜
外部驗證	✅	✅	✅	✅
缺失值處理	✅	✅	⬜	✅
校準 (calibration)	✅	⬜	⬜	⬜
Bias/Fairness 分析	✅	✅	✅	✅
可解釋性/可解讀性	⬜	⬜	✅	✅
人機比較 (human vs AI)	⬜	✅	✅	✅
適用指引	TRIPOD+AI	STARD-AI	CLAIM	DECIDE-AI

B5 ↔ Hook E 的分工：B5 在 Phase 5-6 做「快速方法學掃描」（10 項以內），Hook E 在 Phase 7 做「完整 EQUATOR checklist 逐條驗證」（20-42 項）。兩者互補不重複。

任何必選項 < 5 分 → draft_action(action="patch") → 2 rounds 後仍 < 5 → 人工介入。

B6 前置條件

Target	前置	原因
Results	Methods	Results 依 Methods 定義
Discussion	Results + Intro	討論 Results 回應 Intro
Conclusion	Discussion	總結 Discussion
Abstract	所有主體	摘錄精華

Advisory only（§22 可重組），審計軌跡記錄跳過。

B7 Section Brief 合規 🆕

依據 manuscript-plan.yaml 逐段比對，確保 Section Brief 被正確實現。

子項	檢查內容	失敗行為
B7a	每段 key_claims 是否在文中涵蓋	draft_action(action="patch") 加入論點
B7b	每段 must_cite 是否出現	draft_action(action="patch") 加入引用
B7c	段落順序/數量 vs plan	⚠️ Advisory（不阻擋）
B7d	該 section 的 asset_plan 項目是否已插入	WARNING + 提示插入圖表
B7e	已插入圖表的 caption_requirements 是否滿足	draft_action(action="patch") 補充圖說

FOR paragraph IN plan.sections[section].paragraphs:
  content = extract_paragraph(draft, paragraph.id)
  FOR claim IN paragraph.key_claims:
    IF claim NOT conveyed in content → ISSUE (B7a)
  FOR ref IN paragraph.must_cite:
    IF ref NOT in content → ISSUE (B7b)

FOR asset IN plan.asset_plan WHERE asset.section == section:
  IF asset NOT inserted in draft → ISSUE (B7d)
  IF asset inserted AND caption_requirements NOT met → ISSUE (B7e)

B7a/B7b 遺漏為 WARNING（1 round draft_action(action="patch") 修正），B7d 為 WARNING，B7e 為 WARNING。 B7c 為 ADVISORY（順序偏離可接受）。

Hook B8: Data-Claim Alignment

在 Results 完成後觸發。驗證統計宣稱與 Methods 一致：

• 統計方法：Results 中使用的檢定必須在 Methods 中宣告
• P-value 閾值：Results 的 p < X 須與 Methods 宣告的 α 一致
• CI 寬度：Results 的 95% CI 須與 Methods 一致
• 軟體：Results 提及的統計軟體須在 Methods 中宣告

#	檢查項	MCP Tool	失敗行為	閾值來源
B8	統計宣稱↔方法對齊	run_quality_checks(action="writing_hooks", hooks="B8")	draft_action(action="patch") Methods/Results 補齊	pipeline.writing.stat_alignment

---

Hook C: post-manuscript（全稿完成後，含分層回溯，最多 N rounds，N = pipeline.hook_c_max_rounds）

#	檢查項	MCP Tool	失敗行為	回溯層	閾值來源
C1	稿件一致性	run_quality_checks(action="writing_hooks", hooks="C1")	draft_action(action="patch")	→ B4	—
C2	投稿清單	run_quality_checks(action="writing_hooks", hooks="C2")	定點修正	—	required_documents.*
C3	N 值跨 section 一致	draft_action(action="read") × N + 數字比對	draft_action(action="patch") 統一	→ A	—
C4	縮寫首次定義	draft_action(action="read") + 全文掃描	draft_action(action="patch") 補定義	→ A	—
C5	Wikilinks 可解析	scan_draft_citations	save_reference_mcp 補存	→ A4	—
C6	總字數合規	draft_action(action="count_words")	精簡超長 section	→ A1	word_limits.total_manuscript
C7	數量與交叉引用合規 🆕	見下方 C7 子項	依子項處理	依子項	assets.*, word_limits.*, references.max_references
C8	時間一致性	draft_action(action="read") × N + Agent 掃描	draft_action(action="patch") 更新過時描述	→ B	—
C9	補充材料交叉引用	run_quality_checks(action="writing_hooks", hooks="C9")	draft_action(action="patch") 補引用	—	—
C10	文獻全文+分析驗證	run_quality_checks(action="writing_hooks", hooks="C10")	補 fulltext/analysis	—	—
C11	引用分布均衡 🆕	run_quality_checks(action="writing_hooks", hooks="C11")

Hook C Cascading Protocol

Stage 1: Full Scan
  → 執行 C1-C7 → 收集 ALL issues
  → 分類: CRITICAL (C1不一致, C3數字錯, C5斷鏈) / WARNING (C2, C4, C6, C7)

Stage 2: Cascading Fix (最多 3 rounds)
  Round N:
    FOR each CRITICAL issue:
      1. 定位到具體 section + 段落
      2. draft_action(action="patch") 修正