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

閉環架構

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

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

四個審計維度：

---

執行審計軌跡（Audit Trail）

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

恢復邏輯：偵測 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 呼叫

強制執行規則

1. Phase 轉換：Agent MUST call pipelineaction(action="validatephase", phase=N) 且收到 PASS，才能開始 Phase N+1
2. Phase 7 Review Loop：Agent MUST call pipelineaction(action="startreview") 開始、pipelineaction(action="submitreview", scores=...) 結束。不可跳過輪次
3. Pipeline 完成：Agent MUST call pipeline_action(action="heartbeat") 確認 completion = 100% 才能宣稱完成
4. 所有 gate 結果自動記錄到 .audit/gate-validations.jsonl，可供 Phase 10 D-Hook 分析
5. 專案結構驗證：validateprojectstructure() 可獨立於 pipeline 呼叫，用於檢查新/既存專案結構完整性
6. Phase > 1 自動前提檢查：pipelineaction(action="validatephase", 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 有完整分析記錄（analysissteps D1-D9、adjustmentscount、lessonscount、suggestionscount 與 count/list 一致性），並產出 meta-learning-feedback.yaml 供下一輪 Agent 直接接續

🛡️ Anti-Compaction 恢復協議

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

第一層：Pipeline 狀態自動寫入

• 所有 gate tools（pipelineaction(action="validatephase"), pipelineaction(action="heartbeat"), pipelineaction(action="startreview"), pipelineaction(action="submit_review")）

完成後自動寫入 projects/{slug}/.mdpaper-state.json 的 pipeline_state 欄位

• 不需要 Agent 額外操作

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

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

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

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

第四層：自動恢復

• workspacestateaction(action="get") 讀取 per-project state → getrecoverysummary() 產出 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 workspacestateaction(action="get")
• 如果 pipelinestate.isactive == true → 直接從 recovery summary 指示的 Phase/Round 繼續
• 如果 writingsession.active == true → 用 draftaction(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 的約束

source-materials.yaml 對全 Pipeline 的約束

Data Anchor Provenance Rule：data-artifacts.yaml 的 dataanchors 不得以 concept.md、agent summary、inferred/estimated 值作為來源。每個數字/統計 anchor 必須引用 ready/ingested sourcematerialid、assetawaredocid、dataartifactid，或可信 data file；若來源素材仍是 pendingassetaware，Hook F4 必須 CRITICAL fail。 | pipeline.hookmaxrounds | Hook A/B/C cascading 上限 | | pipeline.reviewmaxrounds | Phase 7 Autonomous Review 輪數 | | pipeline.writing.antiai | Hook A3 Anti-AI 嚴格度 | | pipeline.writing.citationdensity | 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 也會詢問用戶）：

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

Code hard gate: journal-profile.yaml + .audit/source-materials.yaml 存在。關鍵欄位是否合理／已由用戶確認是 workflow 判斷，不由 Phase 0 validator 逐欄驗證。

---

Phase 1: PROJECT SETUP

Skill: project-management

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

Code hard gate: drafts/、references/、data/、results/、.audit/、.memory/ 存在。paper type 對齊是 setup workflow 要求；Phase 2 起另以 project.json 作前置條件。

---

Phase 2: LITERATURE SEARCH

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

1. generatesearchqueries(topic, strategy="comprehensive")
2. 並行 unified_search() × 3-5 組
3. 以 read_session(action="pmids") 取回 PMID，並以 PMID/DOI 去重
4. getcitationmetrics(sortby="relativecitation_ratio")
5. 選前 15-20 篇 → savereferencemcp(pmid, agent_notes)
6. [Optional] Zotero: searchitems(query) → 取 PMID → savereference_mcp()

Code hard gate: Paper-type-aware 最低文獻數 + 每筆 reference 有穩定 identity 與誠實 trust provenance。搜尋策略／選文紀錄缺失只警告。

解析優先序：journal-profile.yaml references.minimumreferencelimits → DEFAULTMINIMUMREFERENCES → DEFAULTMINREFERENCES (15)

自動決策：< minimum → expandsearchqueries；>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. listsavedreferences() → 取得所有已儲存文獻清單
2. 對每篇文獻：

a. 查詢 PDF 來源：getfulltext(pmcid) （pubmed-search MCP）或 analyzefulltextaccess(pmids) 確認 Open Access 狀態 b. IF 全文可取得： - 取得全文：pubmed-search getfulltext(pmcid, sections="all") 或下載 PDF - 解析全文：asset-aware ingestdocuments(filepaths=[pdfpath], usemarker=true) - 等候處理：getjobstatus(jobid) 直到完成 - 建立索引：inspectdocumentmanifest(docid) 取得完整資產清單 - 提取關鍵段落：getsectioncontent(docid, sectionpath) → Methods, Results, Discussion - 更新 metadata.json：加入 fulltextingested: true, assetawaredocid, fulltextsections c. IF 全文不可取得： - 記錄原因：metadata.json 加入 fulltextingested: false, fulltextunavailablereason: "..." - ⚠️ 此文獻在寫作時僅能引用其 abstract 中的結論性資訊，不可引用具體方法或數據

1. Subagent 閱讀分析（CRITICAL — 每篇一個 subagent）：

a. 主 Agent 呼叫 getreferenceforanalysis(pmid) → 取得結構化全文包（≤30K 字元） b. 用 runSubagent 啟動獨立 subagent，prompt 包含： - 全文內容（步驟 a 的結果） - 分析指令：摘要、方法學評估、關鍵發現、限制、可用於文章哪些章節 - 要求 subagent 呼叫 savereferenceanalysis(pmid, summary, methodology, keyfindings, limitations, usagesections, relevancescore) c. Subagent 完成後，analysis.json 已寫入 reference 目錄，metadata.json 標記 analysiscompleted: true d. 主 Agent 後續寫作時只使用 analysissummary，不再重讀全文 → 零 context 汙染

1. 產出 references/fulltext-ingestion-status.md：

Code hard gate: fulltext-ingestion-status.md 非空；每篇文獻都有可驗證 ingestion evidence 或明確 fallback；analysiscompleted: true 必須對得上目前 source revision 的 analysis artifact；primary user materials 不得仍為 pendingasset_aware。 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 閱讀全文？未讀全文的文獻標記 ⚠️

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

1. 標記低品質文獻（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. draftaction(action="write", filename="concept.md", content=..., skipvalidation=True)
4. validation_action(action="concept")(project=...)
5. IF score < 75:

- 自動修正 1 次 → 再驗證 - 仍 < 75 → CGU: deepthink / sparkcollision / generate_ideas → 修正 → 再驗證 - 仍 < 75 → STOP，回報用戶（附 CGU 建議）

Code hard gate: concept.md 含 NOVELTY / KEY SELLING POINTS、structured concept review 完整，且 decision 可採用（通常為 readiness=ready），或可信 host/UI 依用戶明確決定簽發 mdpaper.conceptreviewoverride.v3 Ed25519 receipt。MCP/Agent 只能查詢或撤銷 receipt， 不得以 approved_by="human" 或直接寫 YAML 冒充人類核准。

CGU 工具對應：

---

Phase 4: MANUSCRIPT PLANNING

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

1. 讀取 concept.md + saved references + journal-profile.yaml
2. 產出 manuscript-plan.yaml（段落級 Section Brief）：

- writingorder: 依 journal-profile.paper.sections，fallback 到 paper type 預設 - sections: 每個 section 包含 wordbudget + paragraphs[] - 每段：id, function, topic, keyclaims, mustcite, wordtarget - 🔒 保護段落標記 protected: true（Novelty Statement / Selling Points） - Methods 段落可含 checklistitems（對應 B5 方法學） - assetplan: 圖/表/流程圖（含 tool, toolargs, caption, captionrequirements） - ⚠️ 驗證總數 ≤ assets.figuresmax + assets.tablesmax - ⚠️ 驗證 ≤ assets.totaldisplayitemsmax - submissionchecklist: 依 requireddocuments.* 列出需準備項目 - metadata: generatedat, basedon, changelog[]

1. Plan 修改規則：

- Agent 可新增段落 / 修改 claims / 調字數 → 需寫入 metadata.changelog - Agent 禁止刪除 protected: true 段落 - 用戶自由修改，changelog 自動追蹤

1. Autopilot 模式（pipeline.autopilot: true，預設）：

- Agent 自行驗證 plan 的完整性（圖表數量、字數預算、section 涵蓋度） - 驗證通過 → 直接存入 projects/{slug}/manuscript-plan.yaml → 繼續 Phase 5 - 驗證失敗 → Agent 自行修正 → 重新驗證（最多 2 輪）→ 仍失敗才詢問用戶 - Plan 摘要記入 .audit/pipeline-run-{ts}.md，用戶可事後查閱

1. 手動模式（pipeline.autopilot: false 或 autopilotpauseat 含 "phase4"）：

- 🗣️ 呈現 manuscript-plan.yaml 摘要給用戶確認 - 用戶調整 → 確認 → 存入

Code hard gate: Phase 3 concept review 仍可採用 + manuscript-plan.yaml（或 legacy drafts/manuscript-plan.md）存在。圖表數量、coverage、approval reason 是本 workflow 的自審／人工審閱要求；目前 Phase 4 validator 未逐欄重算。

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

---

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）

1. 在 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

1. 建立 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）

Anti-patterns（自動 FLAG）：

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

Methods 段落模板（Reproducibility Structure）

Anti-patterns：

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

Results 段落模板（Data-First Structure）

Anti-patterns：

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

Discussion 段落模板（Interpretation Structure）

Anti-patterns：

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

Abstract 段落模板（Structured Abstract）

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

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

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 → savereferenceanalysis() 建立 usage_sections
2. Phase 5 → 每次 insertcitation() 時，同步更新 citationdecisions.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 需外部工具

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

Workflow exit target: Hook C/F 已處理至沒有未解決 CRITICAL（warnings 記錄但可接受）。Code hard gate 另驗證 quality-scorecard / hook-effectiveness 的有效資料與 data-artifact report；目前 validator 不在 Phase 6 內重跑全部 A/B/C hooks，也不單獨解析 unresolved-critical count。

Cascading 回溯規則

---

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 完成 → pipelineaction(action="validatephase", 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 minrounds=2）。 上限：pipeline.reviewmaxrounds（預設 3）。 最低輪數：minrounds=2（Code-Enforced：AutonomousAuditLoop.determineverdict() 在 round < minrounds 時強制返回 CONTINUE，不允許提前結束）。 Hard Gate：每輪 MUST call pipelineaction(action="startreview", minrounds=2) 開始 + pipelineaction(action="submitreview", scores=...) 結束。Phase 7 固定安全下限為 minrounds >= 2、qualitythreshold >= 7.0、maxrounds <= 10，序列化狀態或專案設定都不能降低。Loop 結束後 pipelineaction(action="validatephase", phase=7) 必須 PASS：除了驗證 rounds、artifact、hash chain、R1-R6 與重算分數，只有 qualitymet 可在自主模式解鎖 Phase 8。maxrounds／stagnated／userneeded 是升級條件；若人類明確接受低於門檻的結果，可信 host/UI 必須簽發 mdpaper.reviewcompletionoverride.v3 Ed25519 receipt，綁定專案、當前稿件與 loop state。MCP/Agent 只能查詢或撤銷，不能鑄造核准。

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

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

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

每位 Reviewer 必須：

1. 搜尋文獻驗證：使用 unifiedsearch / findrelated_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) 接受當前品質：由可信 host/UI 收集具名 reviewer、rationale 與 accepted risks，簽發 state-bound `mdpaper.review_completion_override.v3` receipt；再呼叫 `pipeline_action(action="approve_review_completion", decision="status")` 驗證。不得由 MCP/Agent 簽發、改寫分數或宣稱 quality_met
      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 指引內建資料庫

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）

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

Review vs Hook 的分工

---

Phase 8: REFERENCE SYNC

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

Code hard gate: Phase 7 已完成 + References section 存在 + citation wikilinks 全部可解析。格式、引用數量／分布是本 workflow 與 C-series/R6 checks，不由 Phase 8 validator 額外重算。

---

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

Skill: word-export

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

Facade 入口仍是 exportdocument(action="docx") / exportdocument(action="pdf")；正式呼叫時必填 draftfilename 與 outputfilename。

1. exportdocument(action="docx", draftfilename="manuscript.md", output_filename="paper.docx") → 產出 DOCX
2. exportdocument(action="pdf", draftfilename="manuscript.md", output_filename="paper.pdf") → 產出 PDF
3. inspectexport(action="listtemplates") → 選擇 template（優先匹配 journal-profile.journal.name）
4. exportdocument(action="sessionstart") → exportdocument(action="sessioninsert") × N
5. 驗證必要文件清單（from required_documents.*）：

- coverletter → 如尚未產生，提示用戶或自動草擬 - authorcontributions → 提示用戶填寫 - ethics_statement → 提示用戶提供

1. inspectexport(action="verifydocument") → exportdocument(action="sessionsave")
2. inspectexport(action="docxsmoke") 或 inspectexport(action="xmlsmoke") → 驗證 DOCX zip/XML 結構、word/document.xml、段落與可見文字

Code hard gate: pipelineaction(action="validatephase", phase=9) — Phase 6–8 前置條件有效，DOCX + PDF 都存在且各自通過 integrity smoke。必要投稿文件清單是下方 submission-readiness advisory task，不是 Phase 9 validator 的額外 hard check。

---

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)

1. 格式最終確認：

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

1. 內容一致性：

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

1. 產出 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 偵測與分類邏輯

Code hard gate: pipeline-run-*.md 含 D7/D8、hook-effectiveness report、runmetalearning evolution event，以及可互相核對的 v2 audit schema、D1-D9、counts/lists/provenance。Project Memory 缺失只警告。

---

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

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

⚠️ Code-Enforced: pipelineaction(action="validatephase", 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. pipelineaction(action="validatephase", phase=11, response_format="json", compact=true) → 驗證 PASS
4. 若專案使用 Git，可選擇 commit/push 作為 provenance；若用戶只是寫 paper，不需要 remote

Code hard gate: pipelineaction(action="validatephase", phase=11) — DOCX/PDF 再次通過 integrity smoke且 Phase 10 仍通過；目前沒有額外 completion-marker 檔案要求。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.hookamax_rounds）

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）：

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

---

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

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）：

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 前置條件

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

B7 Section Brief 合規 🆕

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

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 中宣告

---

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

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") 修正
      3. 觸發 回溯層 的 Hook（見上表）確認 patch 品質
    → re-run Hook C

Stage 3: C8 Temporal Consistency Pass
  → C1-C7 全過後，執行 C8 逆向掃描
  → IF C8 發現過時引用 → draft_action(action="patch") 更新 → 重跑 C1 確認一致性

Stage 4: 人工介入（3 rounds 後仍 CRITICAL）
  → 生成 quality-scorecard.md（量化分數）
  → 呈現具體問題 + 建議修改方案
  → 用戶選擇：修改 / 接受風險 / 回到 Phase 5

Hook C 修正策略：
  C1 不一致: 統一術語 → 統一語氣 → 重寫弱 section
  C3 N 值: 以 Methods 定義為準 → 更新所有 sections
  C4 縮寫: 找首次出現 → 加全稱 → 後續只用縮寫
  C5 斷鏈: validate_wikilinks → save_reference_mcp → manual
  C6 字數: 刪冗餘 → 合併段落 → 詢問用戶刪哪段
  C7 數量: 依子項分別處理（見下方）
  C8 過時: 逆向掃描 → draft_action(action="patch") 更新 → 重跑 C1
  C11 引用分布: 找缺引用 section → 補引用 → re-run A2
  C12 引用審計: 生成 citation_decisions.json → 每篇引用留 justification
  C13 圖表品質: 修正順序 → 補 caption → 確保 Results 有圖表引用

C7 數量與交叉引用合規（D5 擴展）🆕

目前 code-enforced 的 C7 family 有三項。字數由 C6、Wikilink 由 C5 處理；引用預算由 Phase 7 R6 處理，不另虛構 C7c/C7e code hook。

orphan = manifest 中有但 draft 沒引用 → WARNING（有圖沒用）
phantom = draft 引用但 manifest 沒有 → CRITICAL（有引用沒圖）

分工：C6 檢查總字數；C5 檢查 citation wikilinks；R6 檢查引用預算。這些都不是 C7 子項。

C8 時間一致性檢查（Temporal Consistency Pass）

根因：寫作順序（如 Methods → Results → Introduction）導致先寫的 section 可能引用「尚未寫」的 section 狀態。當後續 section 完成後，先前的描述變成過時。

觸發時機：Phase 6，Hook C1-C7 之後

檢查流程：

1. 按寫作順序逆向掃描(最早寫的 section 最後檢查)
2. 在每個 section 中搜尋以下模式：

- "not yet written" / "尚未撰寫" - "Deferred" / "deferred" - "will be" + section 名（如 "will be discussed in Discussion"） - Hook 狀態引用（如 "B2: Deferred"） - 對其他 section 內容的斷言（如 "the Introduction contains..."）

1. 對每個匹配項，驗證：被引用的 section 是否已存在？描述是否仍然正確？
2. 不正確 → draft_action(action="patch") 更新為實際狀態

實作：

FOR section IN reverse(writing_order):
  content = draft_action(action="read", filename=section)
  FOR pattern IN temporal_patterns:
    matches = scan(content, pattern)
    FOR match IN matches:
      referenced_section = extract_section(match)
      IF referenced_section EXISTS AND match.claim != actual_state:
        draft_action(action="patch")(section, old=match, new=actual_state_description)
        log_to_audit("C8: Updated stale reference in {section}")

失敗行為：draft_action(action="patch") 更新過時描述。最多 2 rounds。

Hook C9: Supplementary Cross-Reference

在全稿完成後觸發。驗證主稿與補充材料之間的雙向引用：

• 主稿中每個 "Supplementary Table/Figure N" 引用在補充材料中有對應
• 補充材料中的每個項目至少被主稿引用一次（孤兒偵測）
• e-prefix 引用（eTable, eFigure）也被追蹤

---

Hook D: meta-learning（Phase 10，閉環核心）

Hook D 不只改進 SKILL — 它改進 Hook 自身（CONSTITUTION §23）。

基礎設施（infrastructure/persistence/）：

使用方式：

from med_paper_assistant.infrastructure.persistence.hook_effectiveness_tracker import HookEffectivenessTracker
from med_paper_assistant.infrastructure.persistence.quality_scorecard import QualityScorecard
from med_paper_assistant.infrastructure.persistence.meta_learning_engine import MetaLearningEngine

tracker = HookEffectivenessTracker(audit_dir)
scorecard = QualityScorecard(audit_dir)
engine = MetaLearningEngine(audit_dir, tracker, scorecard)
result = engine.analyze()  # → {adjustments, lessons, suggestions, audit_trail, summary}

D1: 效能統計

HookEffectivenessTracker 記錄每次 hook 評估事件（trigger/pass/fix/false_positive），持久化至 .audit/hook-effectiveness.yaml。

效能判斷（§23）：

• 觸發率 > 80% → Hook 太嚴格，建議放寬閾值
• 觸發率 < 5%（超過 5 次執行）→ Hook 太鬆/過時，考慮移除
• 誤報率 > 30% → 判斷標準需修正

QualityScorecard 追蹤 7 個標準維度的品質分數，持久化至 .audit/quality-scorecard.yaml。

D2: 品質維度分析

MetaLearningEngine.d2analyze_quality() 對 QualityScorecard 的 7 維品質分數做深度分析：

• 弱項偵測：score < 6.0 的維度 → 產出 quality_gap lesson
• 缺項偵測：未評估的維度 → 產出 process_gap lesson
• 趨勢判斷：平均分 ≥ 8 → achievement，< 6 → critical review needed
• 維度 → Hook 映射：methodology → B5, textquality → A3, equatorcompliance → E1-E5

D2 的 lessons 輸入 D3（調閾值）和 D4-D5（改 SKILL），形成分析鏈。

D3: Hook 自我改進

MetaLearningEngine.d1d3analyzehooks() 根據 tracker 推薦產生 ThresholdAdjustment：

自動調整（auto_apply=True，變動幅度 ≤ ±20%）：

• 觸發率過高 → 放寬閾值 +15%
• 觸發率過低 → 收緊閾值 -15%

需用戶確認（auto_apply=False）：邏輯修正、新增/移除 Hook

禁止修改：CONSTITUTION 原則、🔒 規則、savereferencemcp 優先、Hook D 自身邏輯

Hook 傳播程序（用戶確認後自動執行）

當 D3 提出新增 Hook 且用戶確認後，依以下 spec 自動同步所有檔案：

Hook Spec 格式（D3 產出）：

hook_id: C7 # 類型字母 + 編號
category: C # A/B/C/D
name: 時間一致性 # 簡短中文名
description: 逆向掃描修正因寫作順序造成的過時引用
check_tool: "`draft_action(action="read")` × N + Agent 掃描"
fix_action: "`draft_action(action="patch")` 更新過時描述"
detailed_definition: |
  #### Hook C7: 時間一致性
  C1-C6 完成後，逆向掃描每個 section...

傳播清單（5 個檔案，按順序更新）：

自動計算：

• new_count = grep 所有 Hook 架構（(\d+) checks） 取得舊值 + 1
• new_range = 解析 Copilot {cat}1-{M} → {cat}1-{M+1}
• 使用 multireplacestringinfile 一次完成所有替換

驗證：傳播完成後 grep -rn "Hook 架構" AGENTS.md .github/ vscode-extension/ 確認數字一致

D4-D5: SKILL + Instruction 改進

MetaLearningEngine.d4d5skillsuggestions() 偵測：

• 某 Hook 觸發 >2 次且修正率 <50% → 加入 pre-check
• 弱品質維度 → 強化對應 Hook（methodology → B5, text_quality → A3）

D6: 記錄審計軌跡

MetaLearningEngine.d6buildaudittrail() 追加寫入 .audit/meta-learning-audit.yaml（append-only 陣列），並由 runqualitychecks(action="meta_learning") 產生 .audit/meta-learning-feedback.yaml，把 pending evolutions 以 agent-readable 摘要回灌到專案。

其他更新：.audit/hook-effectiveness.md, .audit/quality-scorecard.md, .memory/progress.md, .memory/activeContext.md, memory-bank/decisionLog.md, 本檔 Lessons Learned

D7: Review Retrospective 🆕

分析 Phase 7 Review Loop 產出，演化 Reviewer 指令（CONSTITUTION §23 L2 級）。

觸發：Phase 10，D6 審計軌跡產生後，作為 D7-D9 回顧鏈的一部分

流程：

1. 讀取 review-report-*.md + author-response-*.md
2. 統計分析：
   - 哪些 reviewer 角色的 MAJOR issues 最有價值（ACCEPT 率高）？
   - 哪些 suggestions 被 DECLINE 最多？→ 可能過度嚴格
   - 哪些 issues 跨 round 反覆出現？→ 修正策略不佳
   - 各 reviewer 角色的有效問題數量分布
3. 產出建議：
   - 調整 reviewer_perspectives 的檢查重點描述（±20%）
   - 記錄到 SKILL.md Lessons Learned
   - 更新 .audit/reviewer-effectiveness.json
4. 禁止：修改 CONSTITUTION 原則、修改 Hook D 自身邏輯

D8: EQUATOR Compliance Retrospective 🆕

分析 Hook E 在 Phase 7 的執行效果，持續改善 checklist 準確性。

觸發：Phase 10，D7 之後

流程：

1. 讀取 equator-compliance-*.md
2. 統計分析：
   - 哪些 checklist items 被標為 N/A 最多？→ 可能不適用該 paper type
   - 哪些 items 反覆 PARTIAL？→ 可能定義不清楚
   - compliance rate 趨勢（Round 0 → N）
   - ESSENTIAL items 的修補成功率
3. 產出建議：
   - 調整 E1 偵測邏輯的 paper_type 映射
   - 記錄到 SKILL.md Lessons Learned
   - 建議新的 ESSENTIAL 分類（若某非 ESSENTIAL 項反覆 miss）
4. 更新 evolution-log.jsonl with meta_learning event

D9: Tool Telemetry Retrospective 🆕

分析 .audit/tool-telemetry.yaml、.audit/pending-evolutions.yaml 與 MCP tool description 使用情況，讓下一輪工具選擇更精準。

觸發：Phase 10，D7-D8 之後，作為 MetaLearningEngine.analyze() 的最後一步。

流程：

1. 讀取 tool invocation telemetry + pending evolutions
2. 統計分析：
   - 哪些工具被誤用、重試或產生 health alert？
   - 哪些 facade action 需要更清楚的 description / aliases？
   - 哪些 pending evolution 應保留到下一輪，而不是本輪自動修改？
3. 產出建議：
   - tool description / guidance 的修正候選
   - 記錄到 meta-learning-audit.yaml 的 analysis_steps.D9
   - 保留需人類確認的 L3 instruction 建議
4. 禁止：自動修改 CONSTITUTION、🔒 規則、save_reference_mcp 優先順序

---

自動決策邏輯

必須停下：Concept < 60（兩次仍低）、Phase 4 大綱 approve、研究方向改變、Phase 6 N 輪 cascading 仍 CRITICAL、Review 連續 2 輪無分數改善、修改 AGENTS.md 核心原則。

自動繼續：Hook A/B WARNING → LOG → 下一步。Hook C WARNING → LOG → Phase 7。Review MINOR → batch fix → 下一輪。Asset fallback 成功 → 繼續。

---

Cross-Tool Orchestration Map

核心原則：Pipeline 定義「何時」→ Skill 定義「如何」→ Hook 定義「品質」→ Review 定義「完成度」。

Phase × 工具矩陣

跨 MCP 傳遞規則

何時跳過外部 MCP

---

Skill 依賴

auto-paper → Phase 0(pre-plan) → project-management(P1) → literature-review + parallel-search(P2) → fulltext-ingestion(P2.1) → concept-development(P3) → draft-writing(P4,5) → evolution-gate(P6.5) → autonomous-review+equator(P7) → reference-management(P8) → word-export(P9) → submission-preparation(P9)

---

閉環檢查清單

• Phase 0: source-materials.yaml 已產生；所有 pendingassetaware 檔案已交給 asset-aware 或有明確 fallback reason
• Phase 0: journal-profile.yaml 已產生 + 用戶確認
• Phase 2.1: fulltext-ingestion-status.md 已建立，每篇文獻標記全文狀態 + analysis_completed
• 所有 section 通過 Hook A（cascading）
• 所有 section 通過 Hook B（含回溯修正）
• 所有 Phase 5 FLAG 已在 Phase 6 處理
• 全稿通過 Hook C（cascading fix）
• Phase 6.5: Evolution Gate baseline snapshot 已建立
• Phase 7: Autonomous Review 達到 quality_threshold（MANDATORY；安全下限至少 2 rounds、threshold ≥ 7.0，不可由 pipeline config 調低）
• Hook E: EQUATOR compliance rate ≥ 80% + 所有 ESSENTIAL items reported
• quality-scorecard.md 已生成（所有維度 ≥ 6 分，含 EQUATOR 維度）
• review-round-\*.md 已生成（每輪完整記錄）
• equator-compliance-\*.md 已生成（每輪 checklist 報告）
• evolution-log.jsonl 包含 baseline + 所有 round 事件
• hook-effectiveness.md 已生成
• .audit/pipeline-run-{YYYYMMDD-HHmm}.md 涵蓋所有 Phase，且含 ## D7 retrospective: + ## D8 retrospective:
• meta-learning-feedback.yaml 已生成，pending evolutions 已回灌到 workspace state
• checkpoint.json 標記完成
• Asset Plan 所有項目已生成或有 fallback 記錄
• 引用數量 ≤ journal-profile.references.max_references
• 圖表數量 ≤ journal-profile.assets limits
• 必要文件清單（required_documents）完成
• .memory/ 已更新
• Hook D meta-learning 已執行（含 D7 Review + D8 EQUATOR + D9 Tool Telemetry Retrospective）
• SKILL.md Lessons Learned 已更新
• Word 已匯出

---

Lessons Learned（Hook D 自動更新區）

Run 2026-02-20: Self-Referential Paper (Software/Methods)

Pipeline: 13 main gate checkpoints + Phase 2.1 sub-gate, fully autonomous, 0 human interventions

1. Proactive Hook Effect: All 6 sections passed Hook A on first write (0 corrections needed). The hook criteria documented in this SKILL.md act as proactive constraints — the LLM avoids prohibited patterns because it knows they will be checked. This means hooks serve dual purpose: reactive verification AND proactive generation shaping.

1. Hook A4 False Positive: Example text [[authoryearpmid]] in the System Architecture section was flagged as invalid wikilink. Action: Detection criteria should exclude placeholder/example patterns. Recommended regex exclusion: patterns matching authoryearpmid or similar template-style tokens. FP rate 100% (1/1).

1. CGU Engine Dependency: CGU in "simple" mode returns empty results for deepthink and sparkcollision. Pipeline must handle graceful degradation — log the limitation and proceed. Full meta-learning assessment requires CGU engine upgrade.

1. Template Path Bug: startdocumentsession resolves template path via file traversal to src/templates/ but workspace templates live in root templates/. Workaround: direct python-docx export. Fix needed in template_reader.py initialization.

1. Concept Gate Override: Score 70 (< 75 threshold) was overridden after 2 correction attempts + CGU failure. The 60 hard-stop threshold proved appropriate — the paper was completed successfully at quality score 91.4%. Consider formally documenting the override decision tree: score ≥ 75 → auto-proceed; 60-74 + consistency 100 + user authority → override with audit; < 60 → hard stop.

1. Non-PubMed References: CS/AI system papers frequently cite arXiv preprints lacking PMIDs. The tiered trust architecture only covers PubMed-indexed literature. Future: extend savereferencemcp to accept DOIs with CrossRef verification as a secondary verified channel.

1. Writing Order Validated: Methods → Results → Introduction → Discussion → Abstract order for Software/Methods papers produced coherent flow. The Introduction was contextually richer because System Architecture, Methods, and Results were already written.

1. Self-Referential Circularity: The system writing about itself creates a bootstrapping challenge — Results data (hook statistics) are generated during writing, but the Results section must describe them. Resolution: write Results with partial data, then verify final numbers match in Hook C. Acceptable for n=1 demonstration.

1. Temporal Inconsistency from Writing Order: When Results is written before Introduction, deferred hook statuses (e.g., "B2: Deferred — Introduction not yet written") become stale after Introduction is completed. Action: Added Hook C7 (Temporal Consistency Pass) to systematically scan for and correct such stale references in Phase 6. Root cause: writing order creates forward-references that need backward-patching.