| 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 |
強制執行規則
- Phase 轉換：Agent MUST call
pipeline_action(action="validate_phase", phase=N) 且收到 PASS，才能開始 Phase N+1
- Phase 7 Review Loop：Agent MUST call
pipeline_action(action="start_review") 開始、pipeline_action(action="submit_review", scores=...) 結束。不可跳過輪次
- Pipeline 完成：Agent MUST call
pipeline_action(action="heartbeat") 確認 completion = 100% 才能宣稱完成
- 所有 gate 結果自動記錄到
.audit/gate-validations.jsonl，可供 Phase 10 D-Hook 分析
- 專案結構驗證：
validate_project_structure() 可獨立於 pipeline 呼叫，用於檢查新/既存專案結構完整性
- Phase > 1 自動前提檢查：
pipeline_action(action="validate_phase", phase=...) 在 Phase > 1 時會自動檢查前置 Phase 的關鍵 artifacts（WARNING 級別）
- 審計數據強制：Phase 6 gate 不只檢查報告檔案存在，還驗證 quality-scorecard.yaml（≥4 維度、avg > 0）和 hook-effectiveness.yaml（≥1 hook 有事件記錄）
- 自我改進數據強制：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
autopilot_pause_at: []
| 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
project_action(action="current") → 有專案就切換，沒有就建立project_action(action="create", name, paper_type) 或 project_action(action="switch", slug)project_action(action="setup")- 載入
journal-profile.yaml → 驗證 paper_type 一致
project_action(action="update", target_journal=journal.name)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）
generate_search_queries(topic, strategy="comprehensive")- 並行
unified_search() × 3-5 組
- 以
read_session(action="pmids") 取回 PMID，並以 PMID/DOI 去重
get_citation_metrics(sort_by="relative_citation_ratio")- 選前 15-20 篇 →
save_reference_mcp(pmid, agent_notes)
- [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。
流程：
list_saved_references() → 取得所有已儲存文獻清單- 對每篇文獻：
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 中的結論性資訊，不可引用具體方法或數據
- 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 汙染
- 產出
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 完成（全文解析結果可用時，品質評估更精確）
-
對每篇核心文獻（≥5 篇）評估：
- 研究設計品質（RCT > cohort > case series > case report > expert opinion）
- 偏差風險（selection, performance, detection, attrition, reporting）
- 樣本量適足性
- 統計方法適當性
- 結論是否有資料支持
- [NEW] 全文驗證狀態：是否已透過 asset-aware 閱讀全文？未讀全文的文獻標記 ⚠️
-
產出品質矩陣（appraisal-matrix.md）：
| PMID | 1st Author | Design | Quality | Bias Risk | Key Limitation |
|---|
| ... | ... | RCT | High | Low | ... |
- 標記低品質文獻（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）
- 分析 saved references → 識別 Gap
- 撰寫 concept.md（含 🔒 NOVELTY + 🔒 SELLING POINTS）
draft_action(action="write", filename="concept.md", content=..., skip_validation=True)validation_action(action="concept")(project=...)- 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}/ 下）
- 讀取 concept.md + saved references + journal-profile.yaml
- 產出
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[]
- Plan 修改規則：
- Agent 可新增段落 / 修改 claims / 調字數 → 需寫入
metadata.changelog
- Agent 禁止刪除
protected: true 段落
- 用戶自由修改，changelog 自動追蹤
- Autopilot 模式（
pipeline.autopilot: true，預設）：
- Agent 自行驗證 plan 的完整性（圖表數量、字數預算、section 涵蓋度）
- 驗證通過 → 直接存入
projects/{slug}/manuscript-plan.yaml → 繼續 Phase 5
- 驗證失敗 → Agent 自行修正 → 重新驗證（最多 2 輪）→ 仍失敗才詢問用戶
- Plan 摘要記入
.audit/pipeline-run-{ts}.md，用戶可事後查閱
- 手動模式（
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），避免主稿完成後才回頭補。
-
根據期刊 profile 判斷是否需要補充材料
-
規劃補充內容：
- Supplementary Tables（大型數據表、子群分析）
- Supplementary Figures（額外結果圖）
- Supplementary Methods（詳細方法學、程式碼）
- 敏感度分析結果
- EQUATOR checklist 完整版（如 CONSORT flow diagram）
-
在 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
- 建立
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"
}
工作流程：
- Phase 2 →
save_reference_analysis() 建立 usage_sections
- Phase 5 → 每次
insert_citation() 時，同步更新 citation_decisions.json
- 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 必須：
- 搜尋文獻驗證：使用
unified_search / find_related_articles 搜尋相關文獻，比對稿件引用是否充分、結論是否與現有證據一致
- 獨立閱讀全稿：不參考其他 Reviewer 的意見
- 提出 5-10 個結構化問題：每個問題必須包含 section、paragraph、category、issue、suggestion
- 文獻比對：至少引用 2-3 篇搜尋到的文獻來支持或挑戰稿件觀點
- 給出獨立評分：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
draft_action(action="sync_references", filename="manuscript.md") → 生成 References section- 確認所有
[[wikilinks]] 已解析
format_references(style=journal-profile.references.style)- 驗證引用數量 ≤
references.reference_limits[paper.type]（fallback max_references）
- 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。
export_document(action="docx", draft_filename="manuscript.md", output_filename="paper.docx") → 產出 DOCXexport_document(action="pdf", draft_filename="manuscript.md", output_filename="paper.pdf") → 產出 PDFinspect_export(action="list_templates") → 選擇 template（優先匹配 journal-profile.journal.name）export_document(action="session_start") → export_document(action="session_insert") × N- 驗證必要文件清單（from
required_documents.*）：
- cover_letter → 如尚未產生，提示用戶或自動草擬
- author_contributions → 提示用戶填寫
- ethics_statement → 提示用戶提供
inspect_export(action="verify_document") → export_document(action="session_save")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: —
目的：投稿前的最終系統性檢查，確保所有投稿要件齊全。
-
檔案清單核對（依期刊 profile）：
-
格式最終確認：
- 字數限制（abstract + main text）
- 圖表數量限制
- Reference 格式（期刊 CSL style）
- 檔案命名慣例
-
內容一致性：
- Title page 作者 == manuscript 作者
- Abstract numbers == main text numbers
- Cover letter 提及正確期刊名
-
產出 exports/submission-checklist.md（✅/❌ 清單）
Gate: submission-checklist.md 全部 ✅ 或用戶確認接受列外
Phase 10: RETROSPECTIVE（閉環核心）
🔔 HOOK D: meta-learning（見下方定義，含 D7 Review Retrospective、D8 EQUATOR Retrospective）
- 回顧執行紀錄 + Hook 觸發統計 + Review 輪次統計
- 更新 SKILL.md Lessons Learned
- 更新 AGENTS.md（如適用）
- 更新 .memory/ 完整紀錄
- 分析 journal-profile 設定是否合理 → 建議微調
- 🆕 D7: 分析 review-report + author-response → 演化 Reviewer 指令
- 🆕 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
流程：
- 確認 Phase 9
.docx + .pdf 已產出
- 確認 Phase 10
.audit/pipeline-run-*.md、.audit/meta-learning-audit.yaml、.audit/meta-learning-feedback.yaml 完整
pipeline_action(action="validate_phase", phase=11, response_format="json", compact=true) → 驗證 PASS- 若專案使用 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") 修正
