academic-army 0.1.0

package/skills/academic-army-architect/SKILL.md

@@ -0,0 +1,336 @@
+---
+name: academic-army-architect
+description: >-
+  Generate or revise a goal-oriented strategic paper blueprint for an
+  autoresearch pipeline. Use when Codex must refine a paper idea, position a
+  submission for a target venue, define claims and contribution boundaries,
+  build an evidence-grounded candidate method space, audit or revise an
+  existing blueprint, or hand off stable paper strategy to downstream content,
+  method, experiment, figure, writing, or review-planning skills. Always create
+  exactly two Markdown artifacts: English-only `paper_blueprint.md` and
+  Chinese-language `paper_blueprint.explain.md`. Use
+  `academic_army_mcp_tools.deepresearch` for live venue, literature,
+  high-quality-paper, method, benchmark, and autoresearch-workflow evidence.
+---
+
+# Academic Army Architect
+
+## Mission
+
+Create a target-oriented paper strategy blueprint for downstream AI planning.
+The blueprint is not a full paper, experiment plan, figure plan, implementation
+plan, or advice checklist. It is the stable paper core that later skills inherit:
+
+- paper identity, target venue, readers, field context, and reviewer posture
+- core thesis, problem pressure, reader promise, and paper goals
+- prior-work boundary and differentiated positioning
+- one to three core claims and the evidence each claim needs
+- contribution shapes and novelty boundary
+- high-level method or system logic
+- experiment-dependent candidate method routes
+- minimum sufficient evidence chain and evaluation principles
+- downstream planning constraints and unresolved strategic variables
+
+Before drafting or auditing output, read
+[`references/blueprint-schema.md`](references/blueprint-schema.md).
+
+## Output Contract
+
+Write exactly two Markdown files in the requested output directory:
+
+- `paper_blueprint.md`: English-only, AI-facing paper strategy blueprint.
+- `paper_blueprint.explain.md`: Chinese-language validation companion for the
+  user. It uses Chinese sentences as the default and preserves conventional
+  English titles, venue names, dataset names, benchmark names, method names,
+  and technical terms when those names are standard in the field.
+
+Keep the output directory limited to these two Markdown artifacts.
+
+`paper_blueprint.md` objectively states the selected paper strategy, claim
+envelope, contribution boundary, candidate method space when needed, evidence
+requirements, downstream inheritance contracts, and open strategic variables.
+It should be usable by later AI skills without reading the Chinese explanation.
+
+`paper_blueprint.explain.md` helps the user validate why the blueprint is
+reasonable. It records user-specified facts, restates each important blueprint
+decision before explaining its rationale, and explains paper-design decisions
+only: idea positioning, venue fit, claim logic, evidence chain,
+source-backed patterns, candidate-method reasoning, and open-variable status.
+It should not explain the skill workflow, template choices, tool calls,
+artifact access, or runtime environment.
+
+## Strategic Level
+
+Operate at paper-strategy levels 0-2 and route tactical work to downstream
+skills.
+
+| Level | This skill owns |
+|---|---|
+| 0: paper identity | idea, field context, target readers, target venue, paper type |
+| 1: thesis and claims | problem pressure, insight, reader promise, goals, claim hierarchy |
+| 2: strategic constraints | prior-work boundary, contribution roles, high-level design logic, candidate method space, evidence principles, downstream contracts, open variables |
+
+Translate tactical inputs into strategic contracts:
+
+| User input type | Blueprint-level representation |
+|---|---|
+| algorithm, proof, or optimization idea | required method property, selected strategic direction, or candidate method route |
+| module or method combination | candidate route with purpose, evidence needed, demotion condition, and fair-comparison principle |
+| dataset, trace, benchmark, device, or baseline | evidence dimension, fairness obligation, or user-specified evaluation constraint |
+| metric formula | outcome family and claim-evidence requirement |
+| figure or section idea | visual or narrative argument that downstream planning must preserve |
+| implementation detail | inherited capability, deployment boundary, or downstream engineering constraint |
+
+## Strategy Ledger
+
+When creating or revising a blueprint, maintain an internal ledger:
+
+1. `User-specified facts`: explicit constraints accumulated across iterations.
+2. `Evidence-backed findings`: live-research findings tied to source links.
+3. `Preferred but not locked`: user preferences that guide the best strategy.
+4. `Working assumptions`: defaults that keep the blueprint coherent.
+5. `Strategic decisions`: identity, thesis, goals, claims, contribution roles,
+   novelty boundary, and scope.
+6. `Candidate method routes`: experiment-dependent approaches that downstream
+   method or experiment planning must compare.
+7. `Rejected strategic alternatives`: plausible alternatives not selected, with
+   a concise paper-level reason.
+8. `Open strategic variables`: unresolved choices that require private facts,
+   unpublished constraints, user preference, or unavailable evidence.
+9. `Resolved since prior iteration`: items closed by user facts, live evidence,
+   experiments, or a documented strategy decision.
+
+When revising an existing blueprint, read the prior
+`paper_blueprint.explain.md` first and preserve accumulated user-specified
+facts unless the user explicitly corrects them.
+
+Use this precedence order:
+
+1. explicit user correction
+2. accumulated user-specified fact
+3. completed experiment result supplied by the user
+4. evidence-backed finding
+5. open strategic variable
+6. preferred but not locked
+7. working assumption
+
+Evidence can refine scope and positioning, but it does not silently override a
+user-specified constraint. Explain any resulting tradeoff in the Chinese file.
+
+## Strategic Judgment
+
+Take responsibility for choosing the strongest current paper strategy. Use the
+paper goal, user facts, live evidence, venue posture, source-backed paper
+patterns, claim requirements, and downstream executability to commit to the
+best-supported position.
+
+When one option is materially stronger, write only the selected strategy in
+`paper_blueprint.md`. In `paper_blueprint.explain.md`, briefly explain why the
+selected route is more persuasive than the most relevant rejected alternative
+when that contrast helps the user validate the design.
+
+Keep an item open only when available information cannot support a reliable
+strategy decision and the choice would materially affect paper identity, claim
+scope, contribution boundary, deployment boundary, evidence chain, or downstream
+contracts.
+
+## Candidate Method Space
+
+Distinguish the strategic method direction from experiment-dependent
+implementation routes.
+
+Commit to a strategic method direction when venue posture, user facts, and
+literature support it. For example: "the paper needs an interpretable online
+controller with explicit uncertainty and deadline handling."
+
+When method superiority depends on future results, create a `Candidate Method
+Space` instead of selecting a final method or asking the user to choose. Each
+candidate route should state:
+
+- strategic purpose
+- source or theoretical motivation
+- relation to the core claim
+- potential contribution role
+- evidence needed to promote it into the proposed method
+- disqualifier or demotion condition
+- fair-comparison principle
+- downstream owner, usually method planning or experiment planning
+
+Candidate routes can later become the proposed method, a baseline, an ablation
+variant, or a rejected route. Baseline planning may include original prior
+methods, single-backbone variants, candidate routes without the paper's key
+mechanism, partial-module variants, or key-module replacements. Leave exact
+experiments, budgets, hyperparameters, and run matrices to downstream planning.
+
+Exclude methods that live research shows are incompatible with the problem,
+inputs, cost envelope, venue posture, or claim needs. Explain the paper-level
+reason in the Chinese file.
+
+## Open Variable Policy
+
+Open strategic variables are a last-resort output. Before preserving one:
+
+1. Check whether it is already settled by user facts.
+2. Check whether completed experiments supplied by the user settle it.
+3. Check whether live evidence and venue-oriented judgment support a clear best
+   strategy.
+4. Convert tactical choices to downstream contracts.
+5. Convert experiment-dependent method superiority questions to candidate
+   method routes.
+6. Commit to a best-supported stance when a reasonable default exists.
+7. Preserve the variable only if private resources, unpublished constraints,
+   user preference, or missing evidence materially affect strategy.
+
+When an open variable remains, give a current best-supported stance and allowed
+strategy-level resolutions. Re-audit existing open variables on every revision
+and shrink the list when new facts or evidence support a decision.
+
+## Live Research
+
+Run live research before drafting or materially revising a blueprint.
+
+Use the exact MCP tool:
+
+- server: `academic_army_mcp_tools`
+- tool: `deepresearch`
+- canonical name: `mcp__academic_army_mcp_tools__deepresearch`
+
+Research should cover:
+
+- current target-venue scope, posture, reviewer expectations, and paper fit
+- closest substrates, nearest competitors, and literature boundaries
+- relevant methods, systems, datasets, benchmarks, code, and theoretical frames
+- recent high-quality storytelling exemplars from the target venue or adjacent
+  venues such as SIGGRAPH, CVPR, SIGCOMM, NSDI, INFOCOM, or field equivalents
+- canonical older precedents that still shape method, benchmark, or evaluation
+  expectations
+- source-backed evaluation patterns affecting the minimum evidence chain
+- autoresearch, paper-writing, literature-review, scientific-discovery,
+  workflow-agent, prompt-template, benchmark, and open-source-tool patterns that
+  improve this blueprint as a downstream AI-planning artifact. Use these
+  findings to improve the blueprint's role as an inheritable planning object;
+  do not dump generic autoresearch background into either artifact.
+
+For storytelling and writing-style patterns, prefer recent papers from the last
+one to three years. For methods, datasets, benchmarks, baselines, and technical
+background, include older canonical work when still load-bearing. Prefer
+primary sources: official venue pages, reviewer guidance, papers, project pages,
+repositories, benchmark pages, datasets, and official documentation. Separate
+source-supported facts from inference.
+
+Use this research prompt shape:
+
+```text
+Research brief:
+[IDEA, TARGET PROBLEM, KNOWN SUBSTRATES, USER-SPECIFIED FACTS,
+PREFERENCES, CURRENT CANDIDATE METHOD SPACE, AND CURRENT OPEN VALIDATION ITEMS]
+
+Target venue:
+[VENUE]
+
+Return concise evidence in nine sections:
+1. Venue posture, target readers, and reviewer expectations
+2. Closest technical substrates and literature boundary
+3. Nearest competing work and differentiated positioning
+4. Recent high-impact storytelling exemplars and why their framing works
+5. Cross-paper synthesis: framing, contribution, and evidence-chain lessons
+6. Canonical method, dataset, benchmark, baseline-family, and evaluation precedents
+7. Candidate method space: plausible routes, combinations, evidence needed, and disqualifiers
+8. Strategy implications: decisions to commit, routes to delegate to experiments, alternatives to reject, and only genuinely unresolved items
+9. Source-role table with title, venue/year, stable link, role, persuasive pattern, and blueprint lesson
+
+Separate source-supported facts from inference. Prioritize sources that
+materially change the paper strategy. Use recent papers for storytelling
+analysis and older papers only for load-bearing precedents. Identify the
+best-supported paper strategy. Label experiment-dependent method routes as
+candidates rather than proven best choices.
+```
+
+In `paper_blueprint.explain.md`, start the research discussion with three to
+five cross-paper patterns. Then explain six to eight load-bearing sources: what
+each source establishes, why its framing or evidence style matters, and which
+blueprint choice it influences.
+
+## Workflow
+
+1. Read the request, prior explanation file when present, and
+   `references/blueprint-schema.md`.
+2. Build or update the strategy ledger.
+3. Shrink candidate open variables using the open-variable policy.
+4. Run `academic_army_mcp_tools.deepresearch`.
+5. Synthesize venue fit, prior-work boundary, storytelling patterns, method
+   families, benchmark expectations, evidence precedents, and blueprint-design
+   implications from autoresearch workflow evidence.
+6. Commit to the best-supported thesis, paper goals, contribution strategy,
+   one to three claims, novelty boundary, and minimum sufficient evidence chain.
+7. Build a candidate method space when method superiority depends on future
+   experiments.
+8. Retain only genuinely unresolved strategic variables.
+9. Draft both Markdown files.
+10. Audit for language separation, strategic level, source support, candidate
+    method routing, open-variable shrinkage, and downstream inheritance.
+11. Confirm exactly two Markdown files exist in the output directory.
+
+## Quality Bar
+
+`paper_blueprint.md` should:
+
+- use semantic headings rather than global lookup-heavy codes
+- state the selected paper strategy directly
+- define the idea, problem, venue fit, target readers, field context, and
+  reviewer expectation
+- position against existing methods, systems, datasets, benchmarks, or theory
+- define one to three core claims and required evidence classes
+- state contribution shapes and how they serve the claims
+- describe high-level method or system logic without tactical implementation
+- define evidence goals, benchmark/baseline/metric principles, and minimum
+  sufficient evidence chain
+- state risks as open variables, claim-calibration rules, or downstream
+  planning constraints
+- define downstream contracts for content, method, experiment, figure, writing,
+  and review planning when relevant
+
+`paper_blueprint.explain.md` should:
+
+- begin with a concise paper-strategy summary
+- record accumulated user-specified facts near the start
+- explain cross-paper patterns and load-bearing sources before detailed
+  blueprint rationale
+- follow the blueprint's heading order when explaining important decisions
+- restate each decision before explaining why it follows from user facts, live
+  evidence, venue posture, high-quality paper patterns, claim needs, and
+  downstream planning constraints
+- explain why candidate method routes remain candidates when experiments must
+  decide them
+- explain unresolved strategic variables as paper-design variables with current
+  best-supported stances
+- use section titles and natural names rather than global codes or mechanical
+  cross-references
+
+## Boundary Checks
+
+Keep the artifacts focused on the paper being designed. Represent detailed
+algorithms, training recipes, implementation steps, section plans, experiment
+tables, figure layouts, run budgets, plotting plans, and reviewer operations as
+strategic constraints, evidence needs, candidate-route conditions, or
+downstream contracts.
+
+Keep user-facing explanation at the paper-design layer. Explain why the paper
+strategy is selected; leave skill workflow, tool rationale, template choices,
+and artifact-management details out of the two blueprint files.
+
+Before delivery, remove or rewrite user-facing reminders such as `Artifact
+cautions`, `Assumptions to validate`, `Do not assume reviewers will run code`,
+workflow notes, access caveats, or implementation to-do lists. If such content
+is relevant to the paper, express it as an objective design constraint,
+evidence requirement, open strategic variable, claim-calibration rule, or
+downstream planning contract.
+
+## Final Response
+
+Return a concise completion note with the two artifact paths, the paper identity
+summary, unresolved strategic-variable names when present, and candidate
+method-space status when present. Paste artifact contents only when the current
+user explicitly requests pasted contents or when the surrounding task contract
+outside this skill requires it. Do not add any extra files to the artifact
+directory.

package/skills/academic-army-architect/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "Academic Army Architect"
+  short_description: "Strategic paper blueprint with Chinese rationale"
+  default_prompt: "Use $academic-army-architect to refine this paper idea into an evidence-grounded strategic blueprint for downstream planning."
+
+dependencies:
+  tools:
+    - type: "mcp"
+      value: "academic_army_mcp_tools"
+      description: "Provides academic_army_mcp_tools.deepresearch for live venue, literature, exemplar-paper, evaluation-precedent, and reviewer-context evidence."
+      transport: "stdio"

package/skills/academic-army-architect/references/blueprint-schema.md

@@ -0,0 +1,345 @@
+# Blueprint Schema and Audit
+
+Read this file before drafting or auditing the two blueprint artifacts.
+
+## English Blueprint Schema
+
+Use semantic headings and natural titles. Local numbering inside one section is
+acceptable when it improves clarity; section titles should carry the meaning
+without requiring lookup-heavy labels.
+
+Use this default structure:
+
+```markdown
+# Paper Blueprint: <Working Title>
+
+## Paper Identity
+## Core Thesis and Reader Promise
+## Target Venue Fit
+## Problem Context and Prior-Work Gap
+## Paper Goals
+## Contribution Strategy
+## Claim-Evidence Architecture
+## High-Level Design Logic and Scope
+## Candidate Method Space
+## Evidence Strategy
+## Downstream Planning Constraints
+## Open Strategic Variables
+```
+
+Omit `Candidate Method Space` only when the method direction is strategically
+settled and no experiment-dependent method route needs to be compared.
+
+Omit `Open Strategic Variables` when no unresolved strategy-level choice
+remains.
+
+### Paper Identity
+
+State the working title, research area, field context, research object, target
+readers, venue, paper type, and closest substrate when applicable.
+
+Keep accumulated user facts in the Chinese explanation; use the English
+blueprint for the selected paper strategy and downstream contracts.
+
+### Core Thesis and Reader Promise
+
+State the core idea, problem pressure, high-level insight, and reviewer-facing
+promise. Keep the thesis compact enough to guide later planning.
+
+### Target Venue Fit
+
+State why the problem matters to venue readers, how the paper matches current
+venue posture, and which contribution and evidence style the fit requires. Use
+live evidence rather than fixed venue stereotypes.
+
+### Problem Context and Prior-Work Gap
+
+State the strongest existing approaches, their key limitation relative to this
+idea, and the differentiated position. Treat inherited components as
+substrates. Describe nearest competing work as a comparison boundary.
+
+Select a single best-supported paper position. Preserve alternatives only when
+they are experiment-dependent candidate routes or genuine open strategic
+variables.
+
+### Paper Goals
+
+Define three to six goals. Each goal states:
+
+- `Objective`: target state.
+- `Role in the argument`: support for the thesis or a core claim.
+- `Success signal`: evidence-level condition showing the goal is met.
+
+Each goal must guide at least one downstream planning area.
+
+### Contribution Strategy
+
+Name intended contribution shapes, such as method, system, dataset, benchmark,
+analysis, theory, measurement, or application insight. State how each
+contribution serves a claim and works with the other contributions.
+
+Distinguish:
+
+- selected strategic contribution direction
+- inherited substrate or prior component
+- candidate method route that still needs experimental convergence
+
+### Claim-Evidence Architecture
+
+Define one to three core claims with natural-language titles. For each claim,
+state:
+
+- claim
+- why it matters
+- supporting contribution components
+- required evidence class
+- calibration boundary if evidence is narrower than the strongest claim
+
+Keep evidence at claim level, not experiment-protocol level.
+
+Treat method, module, dataset, or benchmark superiority as evidence-backed only
+when completed evidence is already supplied by the user; otherwise place the
+choice in the candidate method space or evidence strategy.
+
+### High-Level Design Logic and Scope
+
+State canonical terminology, conceptual mechanism, positive scope, inherited
+capabilities, explicit novelty boundary, and important risks or weak points for
+later planning. Leave formulas, modules, parameters, training details, and
+engineering steps to downstream skills.
+
+Express selected strategies as decisions. Express experiment-dependent method
+families in `Candidate Method Space`, not as final conclusions.
+
+### Candidate Method Space
+
+Use this section when method superiority depends on future experiments. This is
+not a user-open question. It is a downstream method/experiment-planning
+contract.
+
+Start with:
+
+```markdown
+This section contains experiment-dependent candidate routes. Downstream method
+and experiment planning must compare these routes before promoting one into the
+final proposed method or converting it into a baseline, ablation, or rejected
+route.
+```
+
+For each route, use:
+
+```markdown
+### <Route name>
+
+Status: candidate; experiment-dependent.
+
+Strategic purpose: <how this route could support the thesis or a core claim>.
+
+Source or theoretical motivation: <source-backed or reasoning-backed basis>.
+
+Potential contribution role: <proposed method core, supporting module,
+baseline candidate, ablation variant, or risk-control mechanism>.
+
+Evidence needed to promote: <claim-level evidence class, not a run matrix>.
+
+Disqualifier or demotion condition: <what result or constraint would make it a
+baseline, ablation, or rejected route>.
+
+Fair comparison principle: <budget, inputs, outputs, protocol, implementation
+quality, or resource-control principle>.
+```
+
+Keep this section strategic: describe route logic, evidence needs, demotion
+conditions, and fair comparison principles while leaving hyperparameters,
+training recipes, ablation tables, and implementation steps to downstream
+planning.
+
+### Evidence Strategy
+
+State:
+
+- minimum sufficient evidence chain for the core claims
+- relevant effectiveness, generalization, robustness, efficiency,
+  interpretability, deployment-value, or insight goals
+- dataset, benchmark, baseline-family, and metric-selection principles
+- method-route convergence evidence when candidate routes remain
+- evidence breadth and fairness obligations
+- evidence-dependent claim calibration
+
+Explain why each evidence class is necessary. Delegate exact datasets,
+baseline implementations, metrics, tables, run matrices, and resource budgets.
+
+When candidate method routes remain, state how downstream experiments should
+convert them into a proposed method, baseline, ablation variant, or rejected
+route. Emphasize fair comparison principles rather than exact experiment
+design.
+
+### Downstream Planning Constraints
+
+Add contracts for relevant planning areas:
+
+```markdown
+### <Planning Area> Contract
+
+Preserve:
+- <strategic invariant>
+
+Delegate:
+- <tactical design space>
+```
+
+Typical areas are content, method, experiment, figure, writing, and optional
+review planning. Downstream skills inherit thesis, contribution boundary, claim
+hierarchy, venue posture, terminology, candidate method space, evidence
+requirements, and open variables. They must raise a strategic-variable update
+before materially changing them.
+
+### Open Strategic Variables
+
+Use this section only for unresolved choices that require user/private
+information and affect paper identity, claim scope, contribution boundary,
+deployment boundary, evidence chain, or downstream contracts.
+
+Place method superiority questions that require experiments in `Candidate
+Method Space`; reserve this section for strategy-level variables that need
+user/private information.
+
+State once:
+
+```markdown
+Default propagation rule: downstream skills must use each variable's current
+best-supported stance unless the user, private project facts, or completed
+evidence resolves that variable.
+```
+
+Then use:
+
+```markdown
+### <Variable name>
+
+Status: unresolved.
+
+Affects: <strategic areas>.
+
+Why unresolved: <why user facts, live evidence, and venue-oriented judgment do
+not yet support a reliable best choice>.
+
+Current best-supported stance: <default propagated to downstream skills>.
+
+Allowed resolutions: <short strategy-level alternatives>.
+```
+
+## Chinese Explanation Schema
+
+`paper_blueprint.explain.md` is a Chinese-language rationale file. Use Chinese
+sentences as the default. Keep English paper titles, venue names, dataset names,
+benchmark names, method names, and technical terms only when those names are
+the conventional field form. Do not mix in English workflow explanation,
+template rationale, or runtime/tooling commentary.
+
+Use this default structure:
+
+```markdown
+# 论文蓝图说明：<Working Title>
+
+## 当前论文方案概括
+## 用户已经明确的内容
+### 已确认约束
+### 偏好但未锁定
+## 当前工作假设
+## 使用的研究信号
+### 跨论文模式
+### 承重信号
+### 额外背景信号
+## 核心出发点
+## 按蓝图顺序解释论文方案
+## 候选方法空间说明
+## 开放验证项
+## 本轮已收缩的开放项
+## 证据变化时如何校准 Claim
+```
+
+Omit `候选方法空间说明` when the English blueprint has no candidate method
+space.
+
+Omit `开放验证项` when no strategy-level question remains.
+
+Omit `本轮已收缩的开放项` on the first run or when nothing was resolved.
+
+### Explanation Rules
+
+- Start with a concise, independently readable paper-strategy summary.
+- Accumulate explicit user facts under `用户已经明确的内容`.
+- Follow English blueprint heading order under `按蓝图顺序解释论文方案`.
+- Restate each blueprint decision in Chinese before explaining its rationale.
+- Explain relationships among thesis, goals, claims, contribution shapes,
+  candidate method routes, evidence chain, venue fit, and downstream
+  constraints.
+- Discuss recent high-impact storytelling patterns from the target or adjacent
+  venues and connect those patterns to the blueprint's choices.
+- When a materially plausible alternative was rejected, briefly explain why
+  the selected strategy better serves the paper goal, venue fit, claims, or
+  downstream executability.
+- When method routes remain candidates, explain why the current stage should
+  not select a unique final method before experiments.
+- Distinguish user facts, evidence findings, preferences, assumptions,
+  candidate method routes, and open validation items.
+- Explain why each open item cannot yet be resolved from user facts, live
+  evidence, venue posture, and paper goals; then state the current
+  best-supported stance and what each resolution changes.
+- Explain claim calibration separately from user-input changes.
+
+Use Chinese sentences as the default. Preserve English terms when they are the
+conventional technical name. Refer to sections by their natural headings or
+plain descriptions rather than lookup-heavy labels.
+
+## Boundary Tests
+
+The artifacts should contain paper-design information, claim-level evidence
+requirements, strategic constraints, candidate method routes, open variables,
+and Chinese paper-rationale explanation.
+
+Before delivery, rewrite tactical or process-level material into paper-level
+strategy. Full paper prose, detailed section plans, run matrices, figure
+layouts, implementation recipes, hyperparameter plans, user-operation advice,
+artifact notes, workflow commentary, and unsupported best-result claims should
+be represented only as contribution boundaries, downstream contracts, evidence
+needs, candidate-route conditions, or claim-calibration rules.
+
+Remove sections or phrases that read like user reminders or artifact/runtime
+warnings, including `Artifact cautions`, `Assumptions to validate`, `Do not
+assume reviewers will run code`, access notes, tool-fallback notes, template
+explanations, and process logs. If a reproducibility, artifact, or assumption
+issue affects the paper strategy, express it as an evidence need, deployment
+boundary, open strategic variable, or downstream planning contract.
+
+## Final Audit
+
+Check:
+
+- exactly two Markdown files exist in the requested output directory
+- `paper_blueprint.md` is English-only, declarative, strategic, and AI-facing
+- `paper_blueprint.explain.md` is Chinese-language, preserves conventional
+  English technical names naturally, is self-contained, and focuses on
+  paper-design rationale
+- accumulated user facts appear only in the Chinese explanation
+- each important rationale first restates the corresponding blueprint decision
+- semantic headings replace lookup-heavy identifier systems
+- readers, venue fit, prior-work gap, goals, contribution strategy, one to
+  three claims, minimum sufficient evidence chain, scope, downstream
+  constraints, and open variables are present when applicable
+- every core claim has a claim-level evidence requirement
+- user facts remain constraints instead of reopened questions
+- open items are strategic, deduplicated, and shrink across iterations
+- experiment-dependent method choices appear as candidate routes rather than
+  user-open validation items
+- candidate method routes include evidence-needed, disqualifier/demotion, and
+  fair-comparison principles
+- selected strategies replace unnecessary menus of plausible paper positions
+- tactical choices are delegated
+- recent storytelling exemplars and load-bearing sources influence the Chinese
+  explanation
+- venue/high-quality-paper analysis is used to justify concrete blueprint
+  decisions rather than dumped as generic background
+- no artifact cautions, workflow explanations, tool-rationale text, access
+  notes, or user to-do reminders remain in either artifact