Skill: c-narcissus/paper-deepread-comic-studio (version 1.2.0)

--- name: paper-deepread-comic-studio description: Deep-read research papers into authoritative, reproducible teaching reports, then turn them into source-grounded multi-image cartoon-comic storyboard workflows with camera/style/logic continuity and final image-PDF assembly guidance. Use when users need rigorous paper understanding plus presentation-ready visual explanations without mixing report generation and image generation in one turn. license: MIT-0 metadata: openclaw: version: "1.2.0" emoji: "📚" requires: anyBins: - python3 - python --- # Paper DeepRead Comic Studio（论文精读漫画工坊） Use this source bundle inside a ChatGPT Project when the goal is to deeply read one paper or a small paper set and turn it into graph-ready, innovation-oriented intermediate artifacts plus coherent cartoon-comic teaching storyboards. This v1.2.0 release strengthens two hard requirements: every deep-read must be detailed enough to reproduce, defend, and teach the paper, and every multi-image cartoon prompt must preserve camera movement, style, logic, source grounding, and continuity with earlier generated images. If the user later asks for graph mining, direction mining, or another downstream stage, pass forward the uploaded deep-read bundle from Project `sources` so the later stage can reuse the same evidence. ## Activation and staged-output protocol When the user invokes this skill for a paper deep read, start with a brief plan before the report. The first execution turn is **text-only**: 1. show the plan; 2. generate and directly display the complete authoritative deep-reading report; 3. state the current status and produced artifacts; 4. tell the user how to ask for the next visual/storyboard step. The first execution turn must **not** generate images. Report generation and image generation are separate phases. Because conversations may be stateless, every status or handoff reply must remind the user to resume with a prompt like: ```text 使用这个skill，根据状态，执行第X步：<要执行的阶段>。 ``` If the next step is continuous cartoon generation, the reminder must explicitly include: ```text 使用这个skill，根据状态，执行第X步：生成多张连续的卡通图，<具体部分>。 ``` If the user does not know the next prompt, tell them they can say: ```text 使用这个skill，根据状态，告知下一步应该问什么。 ``` ## Staged cartoon storyboard and PDF assembly protocol After the complete text-only report has been delivered, the user may request separate visual steps. Each step generates one coherent part of a unified cartoon-comic storyboard. Keep style, protagonist, color palette, typography, panel numbering, camera logic, and narrative logic consistent across all visual steps. Hard separation rules: - Do not generate images in the same assistant response that generates the full deep-reading report. - Do not mix long textual report generation and image generation in the same assistant response. - Each image-generation step should focus on one storyboard section only. - Each storyboard section should be split into multiple separate cartoon images/cards. Do not compress different paper sections, claims, or storyboard scenes into one overloaded image. - The final PDF assembly step must not create new images; it only combines already-generated images into a paginated PDF. Multi-image prompt contract: - Whenever a text reply provides an image-generation prompt for continuous cartoon images, explicitly require **multiple separate 16:9 images/cards**, ordered by `第1张`, `第2张`, and so on. Each image should carry one scene, claim, or mechanism step. - Include camera direction for the batch: establishing shot, medium shot, close-up, over-the-shoulder view, zoom-in, pan, cutaway, or transition as appropriate. The camera plan should make the sequence feel continuous rather than a set of unrelated posters. - Include a style bible for the batch: same protagonist/narrator, line quality, color palette, typography, panel numbering, icon language, formula rendering style, and source-tag treatment. - For later visual batches, explicitly reuse the visual bible and continuity notes from earlier generated images. If earlier images are unavailable in context, restate the last known style and ask for or infer only non-factual visual continuity, never new paper facts. - Before writing or sending a prompt, check it against the original paper source and the prior authoritative deep-reading report. Paper-specific numbers, baselines, module names, equations, datasets, claims, figures, and limitations must be traceable to the PDF, LaTeX, or report. - Distinguish `paper-explicit`, `report-derived`, `reasonable inference`, `nearby-work inference`, and `missing / not reported` in the prompt notes when a visual detail depends on evidence strength. - If different parts of the paper need images, split them into separate batches or separate images. Do not merge background, method, experiments, limitations, and future directions into a single all-in-one picture. - Keep visual density teachable: one main idea per image, readable labels, limited text, formula snippets only when needed, and visible uncertainty markers such as `未报告` for missing experimental details. Default staged visual workflow: 0. **Text-only deep read**: plan, complete report, current status, produced artifacts, and next-step prompts. No images. 1. **Background / old-method defects / paper problem / inspiration**: multiple continuous cartoon images explaining why the problem matters and what previous methods miss. 2. **Algorithm overview and modules**: multiple continuous cartoon images explaining input construction, encoding layer, pairwise compatibility modeling, boundary-based anomaly detector, training and inference. 3. **Experiment section**: multiple continuous cartoon images for datasets, baseline taxonomy, metrics, results, ablations, qualitative plots, and reproducibility gaps. 4. **Limitations and defense**: multiple continuous cartoon images for reviewer-style concerns, overclaim guardrails, weak evidence, and defensible answers. 5. **Future directions and innovation graph**: multiple continuous cartoon images for hidden assumptions, new directions, next experiments, and research agenda. 6. **Cover / summary / Q&A backup visuals**: title cover, final recap, oral-defense backup cards as separate images. 7. **Final image-PDF assembly**: collect all approved storyboard images, sort them in story order, verify page count and visual order, and export one 16:9 PDF handoff. Platform guidance for image steps: - ChatGPT web/app: use **Create image** for storyboard image generation. - Codex / Claude Code / coding-agent environments: if the `imagegen` skill is available, prefer it for storyboard image generation. If `imagegen` is unavailable or insufficient, call **ChatGPT Images 2.0 API** or another approved image-generation API. - Do not use SVG diagrams as a substitute for the requested cartoon-comic storyboard images. Storyboard source-grounding rule: - Image/storyboard steps may be grounded in the **uploaded PDF**, the **LaTeX source**, or both. - If a PDF is available, use rendered pages, figure/table locations, visible diagrams, captions, axes, and numeric tables as visual evidence. - If LaTeX source is available, use `figure`/`table` environments, captions, labels, `\includegraphics` paths, equations, section text, and appendix/source files as evidence. - If both PDF and LaTeX are available, cross-check them: use the PDF for visual layout and rendered appearance, and use LaTeX for exact captions, labels, equations, figure filenames, and text around the figure. - The authoritative deep-reading report remains the primary source of truth for storyboard planning. If PDF and LaTeX conflict, note the conflict in a text-only status turn rather than silently inventing content. - When an image prompt uses paper-specific values, diagrams, or claims, those details must be traceable to the PDF, LaTeX source, or the authoritative report. Platform guidance for the final PDF assembly step: - ChatGPT web/app: use the available file/Python/PDF workflow to place one approved image per 16:9 page and export a single PDF. - Codex / Claude Code / coding-agent environments: use a local script such as `scripts/assemble_storyboard_pdf.py`, PIL/Pillow, ReportLab, or another approved PDF library. - Verify that pages are in the intended order, no image is clipped, and the PDF preserves the 16:9 slide aspect ratio. - Recommended output names: `paper_storyboard_all_images.pdf` and, if useful, `paper_storyboard_images_and_pdf.zip`. ## Upstream input contract This stage should be restartable from a fresh session using only the previous stage's uploaded zip plus status and directory descriptions. The upstream delivery should therefore include: - one complete paper bundle zip - `metadata/routing_status.json` - `metadata/project_directory_index.json` - `reports/project_directory_index.md` - `metadata/paper_batch_manifest.json` - per-paper `metadata/source_record.json` - when available, `metadata/openreview_rebuttal_digest.json` For each materialized paper, the upstream `source_record.json` should already expose at least: - `canonical_paper_page_url` - `conference_paper_url` - `conference_pdf_url` - `openreview_forum_url` - `openreview_pdf_url` - `arxiv_abs_url` - `arxiv_pdf_url` - `arxiv_latex_url` - `preferred_source_type` - `preferred_local_source_path` - `local_latex_dir` - `local_pdf_path` - `local_openreview_pdf_path` - `local_official_pdf_path` - `local_arxiv_pdf_path` - `review_bundle_dir` - `review_digest_path` - `canonical_review_source_type` - `retrieval_sources` - `verification_state` - `verification_checks` - `source_acquisition_status` - `source_stage` - `artifact_status` - `review_bundle_completeness` The deep-read stage should read `routing_status` and `project_directory_index` before browsing the tree ad hoc. Do not guess missing structure from filenames if these two files are present. When available, also read `metadata/delivery_bundle_manifest.json` before ad hoc browsing. It is the authoritative restart contract for fresh-session handoff. If the user provides multiple PDFs, process them as one bounded batch and keep both: - per-paper outputs - a cross-paper comparison artifact when it helps graph building or topic selection For each paper, generate one standalone authoritative detailed report. Do not merge multiple papers into one only detailed report. The report must be at least as rich as the examples under `E:/论文调研/reports/accepted_papers/*.md`, and it must also include the extra graph-ready and direction-mining sections required by this stage. Treat those accepted-paper examples as the minimum top-conference deepread bar for the main narrative, not just for the appendix. ## Research-generative overlay: read for new ideas, not only for understanding This skill now includes the `Research-Generative Paper Reading` lens. Apply it as a **mandatory overlay** on top of all original `paper_deep_reading_skill` requirements. ### Non-weakening and conflict-resolution rule - Do not remove, weaken, shorten, or bypass any existing paper-deep-reading requirement, including source contracts, formula preservation, proof-to-practice mapping, figure/table analysis, reviewer-lens audit, OpenReview handling, structured appendix, validation, and handoff rules. - If a tension appears between the old deep-read requirements and the research-generative overlay, choose the interpretation that is **most useful for discovering new research ideas**, while still satisfying the original requirement. - Do not claim certainty about private author thoughts. Always distinguish paper-grounded evidence from plausible reconstruction. - Generic future-work suggestions are not enough. Convert hidden assumptions, unavailable mechanisms, proxy mismatches, and fragile links into concrete research directions. ### Core research equation For every paper, explicitly extract the paper's research equation: \[ \text{Paper} = \text{Important Setting} + \text{Broken Assumption} + \text{Borrowed Tool} + \text{New Constraint} + \text{Surrogate Mechanism}. \] Also express the paper as: \[ A(P) \cap \neg C \cap T \cap M \Rightarrow Z \approx Y. \] Where: - \(A(P)\): an existing paradigm that solves an important problem \(P\); - \(C\): a common assumption in prior work; - \(\neg C\): the target setting where the assumption fails; - \(T\): a realistic constraint such as privacy, decentralization, non-IID data, low labels, safety, latency, limited compute, missing modalities, or distribution shift; - \(M\): a method family that almost transfers; - \(Y\): the ideal mechanism normally required by \(M\); - \(Z\): the paper's new surrogate mechanism for \(Y\). The report must answer: **what unavailable mechanism did the authors replace, and how did they make the replacement feel inevitable?** ### Author-side direction discovery Add a research-discovery reconstruction using: \[ \text{New Direction} = \text{Valuable Field} + \text{Painful Assumption} + \text{Emerging Tool} + \text{Unserved Setting}. \] For each central idea, identify: 1. the popular paradigm; 2. the hidden assumption; 3. the realistic violation; 4. the tempting borrowed method; 5. the blocking constraint; 6. the authors' conceptual replacement. Use phrases such as: - "A plausible author-side thinking path is..." - "The paper's setup suggests..." - "This is an evidence-backed reconstruction rather than a factual claim about the authors' private thoughts." ### Story-construction and module logic For each paper, reconstruct the story bridge: \[ \text{Challenge}_i \rightarrow \text{Failure Mode}_i \rightarrow \text{Design Principle}_i \rightarrow \text{Module}_i \rightarrow \text{Ablation}_i. \] Create a table: | Challenge | Failure mode | Design principle | Module | Evidence | |---|---|---|---|---| Then decide whether the method is a weak additive story: \[ M_1 + M_2 + M_3 \] or a stronger closed-loop story: \[ M_1 \Rightarrow M_2 \Rightarrow M_3 \Rightarrow M_1. \] Name the object that flows through the loop, such as pseudo-labels, generated data, graph consensus, uncertainty, prototypes, rewards, or memory. ### Module author-thinking template For every major module, use this template in addition to the existing formula/module critique: \[ M_i = \text{Failure} + \text{Unavailable Ideal Solution} + \text{Available Proxy} + \text{Design Choice} + \text{Assumption} + \text{Risk}. \] The report must identify: - what would fail without the module; - what ideal solution would solve it in an easier setting; - what proxy signal/resource remains available; - how the authors convert the proxy into a mechanism; - the hidden assumption \(H_i\); - the failure case under \(\neg H_i\); - the new research idea created by attacking \(\neg H_i\). ### Reverse citation logic Do not only list related work. For important citations, infer their narrative function: | Citation cluster | Narrative function | Assumption inherited | How this paper modifies it | |---|---|---|---| Treat citations as permissions to make moves such as: field foundation, limitation evidence, method ancestor, neighboring-field transfer, strong baseline, benchmark protocol, implementation machinery, or negative contrast. ### Experiments as story evidence Read each experiment as: \[ \text{Experiment} = \text{Claim} + \text{Counterfactual} + \text{Metric} + \text{Stress Condition}. \] For every major experiment block, state: - which claim it supports; - which alternative explanation it rules out; - which module or design choice it justifies; - whether the stress condition actually matches the target hard setting; - whether the ablation proves the module's narrative role or only reports a performance drop. ### Reusable paper-making pattern Extract at least one reusable story template from the paper, especially: \[ A \text{ solves } P \text{ when } C; \quad T \Rightarrow \neg C; \quad M \text{ helps but requires } Y; \quad Y \notin T; \quad Z \approx Y. \] Also look for: - replacement story: easy-setting resource \(Y\) is unavailable, so the paper designs \(Z\); - two-axis empty-cell story: prior work solves each difficulty separately but not their intersection; - closed-loop contribution story: noisy signal -> proxy resource -> better coordination -> cleaner signal; - boundary-pushing story: make a module work when its hidden assumption fails. ### Weakness-to-new-idea conversion For each major weakness, use: \[ \text{Weakness} = \text{Claim} - \text{Evidence} + \text{Hidden Assumption}. \] Then convert it into: \[ \text{Future Work} = \text{Current Method} + \text{Violated Assumption} + \text{New Mechanism}. \] Prioritize directions that expose scientific frontier questions rather than only engineering refinements. ## Teaching-Explainer overlay: read so the paper can be taught to others This skill now includes the `Teaching-Explainer Paper Reading` lens. Apply it as a **mandatory overlay** on top of the original deep-reading and research-generative requirements. ### Non-weakening rule for teaching outputs - Do not replace the authoritative detailed report with a short teaching summary. - Do not omit formulas, proofs, figure/table analysis, reviewer concerns, OpenReview context, research-equation analysis, structured appendix, validation, or next-stage handoff because the user wants a clearer explanation. - Teaching clarity is an extra constraint: make the report easier to explain **after** the full evidence-grounded deep read is complete. - If a simplified explanation would hide an important assumption, formula term, negative result, failure mode, reviewer concern, or evidence gap, include both the simplified explanation and the rigorous caveat. - Keep epistemic discipline: mark whether a teaching claim is paper-grounded, inferred, externally contextualized, or a deliberately simplified analogy. ### Teaching source inspirations to integrate The teaching layer distills public best practices from paper-reading seminars, reviewer guides, and paper-analysis skills. It should be used as a method, not as a citation substitute inside the paper report. - Use a multi-pass reading logic inspired by the three-pass method: first identify the paper's shape, then understand the content, then reconstruct the work deeply enough to critique and teach it. - Use role-based critical discussion inspired by role-playing paper-reading seminars: separate the archaeologist, bug hunter, researcher, practitioner, social-impact assessor, and author-defender viewpoints. - Use a seminar-presentation target: high-level idea, key technical details, experimental results, background/related work, limitations, and 3-5 discussion questions. - Use an introduction-story target: problem, motivation, solution, and contributions, then work backward from contributions to reconstruct the teachable narrative. - Use reviewer criteria as teaching checkpoints: soundness, significance, novelty, clarity, relation to prior work, reproducibility, experimental design, statistical rigor, and evidence-to-claim alignment. - Use architecture-diagram and epistemic-tag discipline from paper-reading skills: each diagram or analogy must distinguish what the paper says from what is inferred for explanation. ### Audience-first explanation contract Before writing the final report, infer or ask for the likely audience when feasible. If the user does not specify, default to: - primary audience: a technically literate graduate student outside the paper's narrow subfield; - secondary audience: a skeptical reviewer or advisor; - tertiary audience: a beginner who needs intuition but not every proof detail. For each paper, the report must include an explicit explanation plan: | Audience | What they already know | What they will likely miss | What must be explained first | How much math to show | What evidence will convince them | |---|---|---|---|---|---| Do not assume that a listener understands the paper's notation, task setting, benchmark culture, or hidden assumptions. Explain these before relying on them. ### Multi-pass teaching read loop Run this loop in addition to the existing workflow: 1. **Orientation pass**: title, abstract, key figures, task setting, and claimed contribution. Produce a one-sentence paper thesis and a one-sentence why-it-matters statement. 2. **Structure pass**: map section-by-section roles: setup, gap, method, theory, experiments, ablations, limitations, rebuttal, appendix. 3. **Mechanism pass**: trace data, symbols, losses, modules, gradients/updates, evidence, and assumptions from input to output. 4. **Virtual reimplementation pass**: explain how one would rebuild a minimal toy version of the method and where the hard parts appear. 5. **Reviewer pass**: challenge novelty, soundness, baselines, reproducibility, claims, figures, and limitations. 6. **Teacher pass**: turn the deep read into a teachable sequence, blackboard derivation, examples, FAQ, and discussion prompts. 7. **Teachback pass**: create questions that test whether a listener really understood the paper rather than memorized the summary. ### Mandatory teaching sections in the authoritative report The detailed report must include these sections in addition to all original sections: - `面向讲解的受众画像与讲解目标` - `3 层讲解摘要：30 秒 / 3 分钟 / 10 分钟` - `讲解主线 Story Spine` - `听众先修知识与概念铺垫` - `公式 / 图表 / 实验的讲解脚本` - `板书推导与小例子演示` - `角色扮演式讨论问题` - `可能被问到的问题与回答证据` - `易误解点与纠偏` - `PPT / 分享稿结构草案` - `听众可带走的三句话` These sections may appear near the end of the main report before the plain-language story summary, or inside a clearly marked teaching appendix, but they must be present in the authoritative report. ### Explanation story spine For each paper, produce a compact teaching spine: ```text Before this paper: The field could do X under assumption C. Pain: In setting T, C fails, so X no longer works. Tempting path: Method family M almost helps, but it requires unavailable mechanism Y. Key insight: The paper constructs surrogate Z for Y. Method: Z is implemented through modules M1, M2, ... Evidence: Experiments/figures/theory show Z helps under stress condition S. Caveat: Z still depends on hidden assumption H. Teaching punchline: The paper's contribution is not just a module, but a replacement story: Y is unavailable, so Z is made useful. ``` This story spine must remain consistent with the research equation: ```text A(P) ∩ ¬C ∩ T ∩ M ⇒ Z ≈ Y ``` ### Explanation ladder Provide explanations at three levels: 1. **Intuition layer**: analogy, plain-language causal story, no equations. 2. **Mechanism layer**: modules, signals, losses, data flow, and why each part is necessary. 3. **Evidence layer**: tables, figures, ablations, theory, reviewer discussion, and limitations. The report must explicitly state what is lost when moving from layer 2 or 3 down to layer 1. ### Deep explanation, reproducibility, and defense contract The report must not be a generic summary. Explain the paper to the level where a reader could reproduce the core method, defend the claims in a review discussion, and teach the logic to another researcher. Use this knowledge-dependency order whenever it is feasible: 1. define symbols, task setting, assumptions, and labels; 2. explain data, inputs, preprocessing, and source evidence; 3. explain the model and modules; 4. explain training objectives, optimization, parameters, and data flow; 5. explain inference, deployment, and outputs; 6. explain experiments, evidence, exceptions, reproducibility risks, and limitations. For every key concept, use the sequence: ```text 直觉 -> 数学公式或 formal definition -> 具体例子 -> 局限 / failure case ``` For every complex module, explicitly state: - input tensors/objects, output tensors/objects, symbols, dimensions, and where each value comes from; - trainable parameters, fixed hyperparameters, objective terms, and update path; - how data flows into the next module during training and during inference; - what would break if the module were removed or replaced; - whether each detail is paper-explicit, report-derived from paper evidence, a reasonable inference, a nearby-work inference, or missing. For missing experimental or implementation details, do not invent. Explicitly list gaps such as hardware, runtime, memory, optimizer, learning rate, seeds, early stopping, hyperparameter search, preprocessing, data split, label definition, baseline source, whether baselines were rerun or reconstructed, code availability, and compute budget. The experiment section must be unusually concrete. Include dataset scale, split protocol, label definition, baseline genealogy, baseline rerun/reconstruction status, metric meanings, main numeric patterns, exceptions to the headline result, ablation purpose, qualitative evidence, and reproduction risk. End the technical explanation with at least one complete numeric toy example that connects training and inference: define tiny inputs, show module outputs or score/loss updates, state which parameters change during training, and then run the learned logic on one inference example. If the paper lacks enough detail for a faithful numeric example, build a clearly marked toy example and state exactly which parts are simplified. ## Staged Cartoon Visual-Storyboard Workflow (mandatory after the report, only when the user asks) This skill supports a second phase for generating presentation-friendly visual storyboards, but **the first execution of the skill must never generate images**. The first execution is a text-only deep-reading delivery. ### Hard separation rule: report text and image generation cannot happen in the same reply - Do **not** generate images in the same assistant turn that delivers the authoritative detailed report, status, or step instructions. - Do **not** mix a long textual explanation with image generation in the same assistant turn. - Text-only turns may provide a plan, status, image-step menu, prompts, and platform guidance. - Image-generation turns should be limited to generating the requested image batch. If using ChatGPT image generation, after the images are generated, keep the assistant's text minimal or empty according to the image tool behavior. - If a user asks for both “show the report” and “draw images” in one message, first complete only the report/status turn, then tell the user exactly which follow-up command will start the next visual step. ### First-run behavior when the skill is invoked When the user invokes this skill for a paper, first respond with a concise plan, then produce only the complete authoritative deep-reading report and required delivery/status information. This first run must include: 1. **Plan**: briefly state the workflow stages that will be used: - Step 0: complete text-only deep read; - Step 1+: staged visual storyboard generation, only after the user asks for a specific step. 2. **Complete deep-reading report**: generate and display the full detailed report satisfying all deep-read, research-generative, teaching-explainer, reviewer-audit, figure/table, formula, experiment, limitation, and handoff requirements. 3. **State and outputs**: tell the user what has been produced and what state the workflow is currently in. 4. **Next-step prompts**: tell the user how to ask for the next step. Include a restart-safe phrase such as: - `使用这个skill，根据状态，执行第1步：生成背景、旧方法缺陷、论文问题与灵感来源的多张连续的卡通图。` - If the user wants continuous cartoon images, explicitly remind them to include: `生成多张连续的卡通图`. - `使用这个skill，根据状态，告知下一步应该问什么。` ### Stateless conversation reminder Assume the conversation may be stateless. In every text-only status or planning turn, remind the user to include the skill name and current state in the next command. Use wording like: > 如果开启新会话或上下文丢失，请说：`使用这个skill，根据状态，执行第X步：生成多张连续的卡通图，...`。如果不知道下一步怎么问，可以说：`使用这个skill，根据状态，告知下一步应该问什么。` ### Visual-generation platform guidance Before starting any image-generation phase, include this guidance in a **text-only planning/status turn**, not in the same turn as image generation: - If the user is using ChatGPT 网页版 / ChatGPT App: use **Create image** mode for the storyboard images. - Do **not** generate SVG diagrams for these storyboard steps. - If the user is using Codex, Claude Code, or another coding-agent environment: prefer the `imagegen` skill when it is available. If `imagegen` is unavailable or insufficient, call **ChatGPT Images 2.0 API** or another available image-generation API to produce the images; do not try to replace the requested cartoon storyboard with SVG-only output. ### Default staged visual storyboard plan After Step 0 is complete, offer a multi-step image plan. The user may request one step at a time. Each step should generate a coherent set of multiple separate 16:9 images in the same visual identity: cartoon-comic academic infographic style, consistent narrator character, consistent title numbering, consistent color palette, clear panels, actual paper data where relevant, camera continuity, and logical continuity. Recommended default steps: | Step | Name | Purpose | Typical image count | Must include | Must avoid | |---|---|---:|---:|---|---| | Step 1 | 背景 / 旧方法缺陷 / 问题与灵感 | Explain why the problem matters before the algorithm | 4-6 | continuous event streams, snapshot limitations, feature scarcity, context mismatch, ambiguous boundary, paper motivation | algorithm internals and experiment results | | Step 2 | 算法整体流程与模块 | Explain BAD from input event to score | 5-7 | current edge `(u,v,t)`, recent-neighbor retrieval, Encoding Layer, Pairwise Compatibility Modeling, Boundary-based Anomaly Detector, training vs inference | final performance results | | Step 3 | 实验部分 | Explain datasets, baselines, metrics, protocols, results, ablations, qualitative plots, reproducibility caveats | 5-7 | Table 1 numbers, 12 baselines, AUC/AP explanation, Table 2 key results, Table 3 ablation, Figure 2/3 qualitative explanation, missing GPU/runtime details | unsupported claims about hardware/time | | Step 4 | 关键局限与答辩质疑 | Prepare defense visuals for limitations and likely reviewer questions | 3-5 | score/boundary caveat, training contamination, cold-start, reproducibility, AP caveat, fairness of baseline protocol | inventing reviewer comments not present in sources | | Step 5 | 未来方向与创新图谱 | Turn the paper into research-direction visuals | 3-5 | hidden assumptions, violated settings, robust flow, inductive compatibility, online conformal boundary, causal/counterfactual compatibility | presenting future work as already validated | | Step 6 | 汇报封面 / 总结 / Q&A backup | Presentation packaging | 2-4 | cover image, final takeaway image, Q&A map | adding new technical claims | ### Visual step execution protocol When the user asks to execute a visual step: 1. Verify which step is requested and whether it follows the current state. 2. If the request is not clear, provide a text-only step menu and ask the user to choose. Do not generate images in that clarification turn. 3. If the request is clear and explicitly asks to generate images, call the image-generation tool directly for that step. Use 16:9 aspect ratio unless the user explicitly changes it. 4. Preserve continuity with earlier generated images when available by referencing their visual style: same cartoon narrator, same title numbering, same panel language, same blue-accent academic-comic style. 5. Ground all factual data in the paper and prior report. If a value is not in the PDF, mark it as missing in a text-only planning/status turn, or show it as “未报告” in an image prompt. 6. Generate multiple separate images/cards for the requested section. Do not collapse a multi-step paper explanation into one dense poster. 7. Encode camera movement and visual pacing in the prompt: establish context, zoom into the mechanism, cut to evidence, then close with caveat or transition when the section needs it. 8. For image steps, do not generate SVG. Use Create image in ChatGPT web/app. In Codex-style environments, prefer the `imagegen` skill when available; otherwise use ChatGPT Images 2.0 API or another approved image API. 9. Do not include detailed report text in the same response as image generation. ### Prompting templates for the user At the end of Step 0 or any text-only status turn, provide concise examples: - `使用这个skill，根据状态，执行第1步：生成背景、旧方法缺陷、论文问题与灵感来源的多张连续的卡通图。` - `使用这个skill，根据状态，执行第2步：生成算法整体流程与各模块解释的多张连续的卡通图。` - `使用这个skill，根据状态，执行第3步：生成实验部分的多张连续的卡通图，包含数据集、baseline、AUC/AP、主结果、消融和复现缺口。` - `使用这个skill，根据状态，执行第4步：生成局限性与答辩质疑的多张连续的卡通图。` - `使用这个skill，根据状态，执行第5步：生成未来方向和创新图谱的多张连续的卡通图。` - `使用这个skill，根据状态，告知下一步应该问什么。` ### Formula teaching rule For every preserved key formula, provide: | Formula | What problem it solves | Term-by-term meaning | How to say it aloud | Where it appears in the algorithm | What can go wrong | |---|---|---|---|---|---| Also include one beginner-friendly concrete example for at least one central formula or update rule. ### Figure and table teaching rule For every important figure/table already analyzed by the deep-read stage, add a teaching script: | Visual | First thing to point at | Listener confusion risk | Claim supported | What not to overclaim | Suggested verbal explanation | |---|---|---|---|---|---| If a figure is visually persuasive but evidentially weak, teach that distinction explicitly. ### Experiment teaching rule Turn each experiment block into a question-answer unit: ```text Question the experiment answers: What a skeptical listener might ask: Setup / dataset / baseline / metric: Expected result if the paper's claim is true: Actual result: What it proves: What it does not prove: How to explain the table or curve in one sentence: ``` ### Role-play discussion pack For each paper, create role-based discussion prompts: | Role | What this role checks | Required output | |---|---|---| | Archaeologist | prior-work ancestry and what is truly new | one older ancestor, one inherited assumption, one modification | | Bug Hunter | rigor, correctness, reproducibility, clarity | three attack questions and one likely author response | | Researcher | future directions and test-of-time value | two follow-up projects, one high-risk boundary idea | | Industry Practitioner | deployability and cost-benefit | adoption conditions, complexity cost, practical failure mode | | Social Impact Assessor | risks, misuse, bias, privacy, safety | one positive impact, one omitted negative impact | | Author Defender | rebuttal and best-paper pitch | strongest acceptance argument and weakest vulnerable claim | | Teacher | whether a non-specialist can follow | analogy, prerequisite list, teachback questions | ### Talk / PPT blueprint rule Do not create a separate final report that competes with the authoritative detailed report. If a talk or slide blueprint is needed, make it a derivative artifact that cites the authoritative report as its source. Minimum slide blueprint: | Slide | Title | One-sentence point | Visual / formula | Speaker notes | Transition | Likely question | |---|---|---|---|---|---|---| Recommended default structure: 1. Why should we care? 2. What was impossible or painful before? 3. What assumption breaks? 4. What is the core idea in one picture? 5. What does the method actually do? 6. What is the central formula / mechanism? 7. How does the algorithm run on a toy example? 8. What experiments prove the claim? 9. What do figures/tables actually show? 10. What are the strongest weaknesses? 11. How would a reviewer attack it? 12. What research directions follow? 13. Three takeaways. ### Q&A and defense rule Prepare likely questions from three audiences: - beginner questions: terms, task, intuition, why not simpler; - peer questions: method details, formulas, baselines, ablations, assumptions; - advisor/reviewer questions: novelty, significance, reproducibility, missing evidence, limitations, next work. For each answer, point back to specific evidence from the paper or state that the paper does not provide enough evidence. ### Misunderstanding guardrails Every teaching report must include: - what the paper does **not** claim; - which simplified analogy could mislead; - which result should not be generalized beyond the paper's tested setting; - which module is easy to mistake for the whole contribution; - which baseline comparison is easy to overinterpret; - which limitation should be stated out loud during a talk. ### Teachback self-test End the teaching section with 8-12 questions a listener should be able to answer after the explanation. Include at least: - one problem-setting question; - one assumption-breaking question; - one method-dataflow question; - one formula interpretation question; - one experiment-evidence question; - one limitation question; - one reviewer-attack question; - one future-direction question. ### Teaching sidecar artifacts When useful, create derivative sidecar artifacts under: - `generated/teaching/<paper-slug>/teaching_outline_cn.md` - `generated/teaching/<paper-slug>/slide_blueprint_cn.json` - `generated/teaching/<paper-slug>/qa_bank_cn.json` - `generated/teaching/<paper-slug>/role_play_discussion_pack_cn.md` These sidecars must not replace the authoritative detailed report. They should cite or reference the sections of the authoritative report they derive from. ## Extended deep-reading rule set The following requirements are mandatory even when they are not strongly emphasized by the original paper: - **Title interpretation rule**: explicitly interpret the paper title term by term. Explain what each keyword means, why the title is phrased that way, and how the title maps onto the actual method, setting, and claims in the paper. - **Mentioned-paper expansion rule**: do not only list cited papers. For the papers that the target paper repeatedly discusses, compare what they solved, what they still left open, and why the current paper needed to move beyond them. - **Multi-layer scientific-problem rule**: explain both the paper-level problem and the upper problem ladder. Prefer continuous ladders such as direction-native -> parent-field -> broader AI/ML, and also discuss algorithm-lineage and bottleneck-derived upper problems when defensible. - **Claim-audit rule**: extract the paper's innovation points and core claims one by one, then audit whether each claim is supported by theory, experiments, ablations, visual evidence, reviewer discussion, or only by suggestive narrative. Say explicitly when support is weak, indirect, or missing. - **Research-thought reconstruction rule**: reconstruct the likely reasoning path that led the authors from observed pain points and prior work to the final design. Also infer what papers, methods, or upper-level scientific problems may have inspired the idea. Separate evidence-backed inference from speculation. - **Author-subjectivity linkage rule**: when discussing the idea, theory, proof choices, algorithm, or modules, explicitly note where the design may reflect the authors' subjective judgments, tastes, priors, heuristics, engineering preferences, or research style. Distinguish objective necessity from author-specific choice whenever the paper gives enough evidence. - **Paper-grounded specificity rule**: do not stay at a generic or abstract summary level. Stay close to the actual paper by naming the concrete modules, symbols, assumptions, losses, theorem objects, datasets, baselines, figures, and experimental findings that the authors actually use. - **Related-work relation rule**: explain the main related-work clusters and state the exact relation between each cluster and the current paper: inherited, contrasted, generalized, specialized, hybridized, or problem-shifted. - **Symbols-and-concepts rule**: explain symbols, assumptions, operators, and problem-specific concepts in beginner-friendly language before relying on them in later sections. - **Formula-preservation rule**: do not drop, compress away, or replace key equations with prose-only summaries. Preserve the paper's core objective functions, update rules, constraints, estimators, bounds, and theorem statements in readable form, then explain each formula term by term and state what role the formula plays in the method. - **Proof-to-practice mapping rule**: if the paper contains theory or proofs, explicitly map theorem assumptions, intermediate claims, and conclusions to the practical algorithm, implementation steps, or system behavior. State whether the implementation is exactly matched to the proved object, only approximately aligned, or only motivated by the theory. - **Theory-purpose rule**: explain why each proof or theoretical claim was included by the authors, what reviewer doubt or scientific concern it addresses, what practical meaning it has, and where the theory stops being faithful to the real implementation. - **Module-and-equation critique rule**: do not stop at restating the design. For each central formula, module, and modeling assumption, judge whether it may be brittle, under-justified, overly heuristic, computationally expensive, hard to optimize, poorly identified, or mismatched to the claimed scientific goal. Then discuss concrete improvement room, alternative formulations, and what trade-offs those changes would create. - **Concrete algorithm walkthrough rule**: the algorithm section must not stop at equations. Give a step-by-step procedure and at least one small concrete example that instantiates the states, inputs, outputs, and updates. - **Experiment genealogy rule**: when baselines are compared in the experiments, explain how those baselines relate to the algorithms and literature introduced earlier in the paper, especially the Introduction and Related Work sections. - **Experiment-purpose rule**: for every major experiment block, state what question it is trying to answer, what reviewer doubt it addresses, and what kind of evidence it produces. Also point out interesting, surprising, or controversial empirical phenomena. - **Reviewer-lens enrichment rule**: enrich the deep-reading report with extra reviewer lenses inspired by strong GitHub paper-review / peer-review skills. At minimum, explicitly audit novelty, significance, technical soundness, methodological rigor, reproducibility, results-claims alignment, missing baselines or controls, figure/table clarity, limitation honesty, and venue-fit or acceptance logic when relevant. - **LaTeX-figure explanation rule**: when a LaTeX source is available, do not ignore figures just because the paper is not being read from a rendered PDF. Reconstruct important figures from figure environments, captions, labels, referenced text, and included image paths when possible, then explain what each figure is trying to show, how it supports the argument, and what it leaves unclear. - **PDF-figure explanation rule**: when a PDF source is available, important figures must also be explicitly interpreted rather than only glanced at. Explain each key architecture figure, pipeline figure, qualitative example, and experimental plot in terms of purpose, visual structure, figure-to-claim mapping, and what remains unclear, potentially misleading, or insufficiently supported. - **Experiment-chart consistency rule**: in the experiment section, explicitly explain important tables, charts, curves, qualitative figures, and numeric comparisons. State which claim each visual or data block supports, whether the evidence really matches the stated claim, and where there is partial support, contradiction, or unexplained mismatch. Analyze plausible reasons for those mismatches instead of smoothing them away. - **Innovation-type rule**: judge whether the work is mainly incremental, cross-domain, boundary-breaking, or a mixture. Explain why. - **Boundary-crossing rule**: discuss whether the paper truly crosses a disciplinary or subfield boundary, or mainly recombines ideas inside one field. - **Limitation rule**: explicitly discuss the paper's weaknesses, unresolved assumptions, failure modes, scope limits, and risks of overclaim. Distinguish between minor limitations and structural limitations that cap the paper's impact. - **Scientific-frontier direction rule**: when proposing future work, distinguish ordinary follow-up engineering from directions that could actually push scientific boundaries. State what new scientific question, cross-field bridge, or conceptual shift would be required for a boundary-pushing follow-up. - **New-direction rule**: speculate about follow-up directions and new innovation hooks, including cross-domain transfer, lateral migration of the method, native extensions of the paper's own line, and higher-risk directions that may open a new boundary rather than only improve a benchmark. - **Story-summary rule**: end with one simple and vivid story that a non-specialist could understand without equations. That means the authoritative report must explicitly cover: - 论文信息 - 论文标题解读 - 这篇论文真正解决的是什么 - 论文中提到的其他论文做了什么、留下了什么空白、与本文是什么关系 - 核心方法到底在干什么 - 公式保留与逐式解释 - PDF 版本关键图解释 - 理论、证明与实现步骤对照 - 具体公式、模块与设计假设的不足及可改进空间 - 创新点、核心主张与证据逐条核对 - 这篇论文为什么重要 / 为什么值得被接收 - 实验是如何被设计出来的 - 倒推作者怎么想到这个 idea - idea / 理论证明 / 具体算法或模块里哪些部分更像作者的主观选择、经验判断或研究风格 - 报告必须结合论文本身的具体模块、公式、图表、实验与措辞，不能停留在过于抽象的泛化总结 - 审稿人最关注什么 - 额外审稿视角审计（借鉴 GitHub 热门审稿 skill 的 reviewer 关注点） - 作者是怎么回复的 - 审稿人是否认同作者回复 - 审稿意见回复覆盖核对 - 强点 / 弱点 / 不足 - 作者团队近年的相关延续 - 未来边界 - 创新类型判断（增量 / 交叉 / 边界突破） - 对选题的直接启示 - 可能的新研究方向或新创新点（尤其是可能推动科学边界的方向） - 通俗生动故事总结 - 参考来源 - 再加上本 stage 需要的结构化补充附录 - 其中结构化附录里必须显式包含“公式保留与逐式解释”“理论、证明与实现步骤对照”以及“具体公式、模块与设计假设的不足及可改进空间” The detailed report length is not capped. Prefer completeness over brevity when the paper warrants it. In ChatGPT Projects, the default input should be one uploaded paper-collection zip in Project `sources`. That zip should contain the paper PDFs and metadata bundle produced by the collection stage. Do not assume a local filesystem paper folder exists. If a clean local scaffold is needed before building the upload bundle, initialize it with: - `scripts/init_paper_deep_reading_scaffold.py` - `scripts/build_paper_deep_reading_bundle.py` - `scripts/validate_detailed_report_structure.py` That scaffold should create: - `metadata/query_spec.json` - `metadata/paper_batch_manifest.json` - `metadata/delivery_bundle_manifest.json` - `metadata/routing_status.json` - `metadata/project_directory_index.json` - `reports/project_directory_index.md` - `reports/stage_delivery_handoff.md` - `reports/per_paper/<paper-slug>/<paper-slug>_detailed_cn.md` ## Core rule Work in stages. If the next step depends on files not yet present in the current Project `sources`, stop and ask the user to upload them first. This especially includes: - paper PDFs - OpenReview review / rebuttal exports - supplementary PDFs - LaTeX source - generated page images - generated visual manifests - generated intermediate Markdown / JSON ## Required layered outputs - broader ML/AI scientific problems - adjacent parent-field problems - higher-problem provenance: - paper-explicit - borrowed-algorithm ancestry - new-algorithm bottleneck - direction-native problems - module-to-problem mapping - graph node candidates - graph relation candidates - related-paper linkage notes - idea-genesis trace - motivation-to-algorithm bridge evidence - rebuttal-aware gap notes - figure analysis - table / chart design analysis - reviewer-lens audit matrix - figure-to-claim mapping - table/chart/data-to-claim mapping - experiment consistency notes - visual prompt blueprint - teaching story spine - audience prerequisite map - formula/table/experiment teaching scripts - role-play discussion pack - Q&A and defense bank - slide/talk blueprint - teachback self-test When extracting upper scientific problems, do not rely only on the paper's own phrasing. Build a progressive problem ladder instead of making a large abstraction jump. Prefer: - direction-native problem - adjacent parent-field problem - broader ML/AI scientific problem Example: - `PFL -> FL -> AI/ML` Do not jump directly from `PFL` to a remote `AI/ML` abstraction if `FL` is the scientifically meaningful middle layer. Only skip the middle layer when no defensible parent-field layer exists, and say so explicitly. Also infer the upper ladder from: - the algorithm families the paper borrows from - the problems or bottlenecks the new algorithm itself runs into Keep those three paths separate in the machine-readable outputs so a downstream graph page can show: - what the paper explicitly claimed - what was implied by borrowed algorithm lineage - what was implied by the new method's encountered bottlenecks For each path, preserve the nearest parent-field layer before the broader ML/AI layer whenever the evidence supports it. ## Review-context rule If the paper is from ICLR, use the paper title and year to find the matching OpenReview forum before writing the review/rebuttal section. Use that forum as the canonical source for reviewer concerns, author replies, and decision context. If the paper came from a previous collection stage, prefer consuming the already downloaded local OpenReview bundle from the project tree instead of re-searching first. The detailed report should explicitly use that local bundle when it exists. If an ICLR paper still lacks `openreview_forum_url`, report that gap explicitly in the machine-readable output and in the human-facing report instead of silently continuing as if review context were complete. If the paper is not from ICLR, do not force a review/rebuttal section by default unless the user explicitly asks for external peer-review context and a reliable public source exists. ## Algorithm-detail rule For the proposed method, prefer extracting more than a short summary. Capture: - model form - architecture summary - key modules - training pipeline - inference pipeline - optimization objectives - communication or deployment path when relevant Also analyze how the paper narrows the gap between motivation and final algorithm. Explicitly look for: - small experiments - probe experiments - pilot or trial model designs - explanatory ablations - toy examples that clarify the update path - visualizations used to justify the mechanism When summarizing the proposed method, do all of the following when the source materials allow it: - define the major symbols before relying on them - separate novel steps from inherited steps - state where each step gets its input and where its output is consumed - give at least one concrete worked example of the algorithm or pipeline - connect each major step back to the motivation it is meant to satisfy For experiments, also require: - explicit mapping from each baseline back to the related-work families introduced earlier - explicit statement of why each experiment block exists - explicit note of surprising, unstable, or controversial findings - explicit discussion of whether the evidence supports only local gains or a broader scientific claim For each one, state what claim it is trying to support and whether it really makes the final method more convincing. Example: - if the paper uses `LoRA`, check whether that points upward to feature alignment, shared-subspace design, or interface-stable transfer - if the new method later depends on cross-family alignment, record alignment as an upper problem even if the paper only framed it as an implementation detail ## No new retrieval rule inside deep reading This stage must not reopen external retrieval. Do not, inside this stage: - reopen author-team search on academic sites - start fresh related-paper harvesting - search GitHub for workflow borrowing - widen source discovery beyond what the uploaded upstream bundle already delivered Instead: - reuse upstream source_record.json, routing_status.json, project_directory_index.json, and any already downloaded review / rebuttal bundle - if upstream materials already contain author-team notes, summarize them - if author-team continuation context is missing, mark it as an upstream gap and defer it back to the download / collection stages - if you notice a retrieval weakness, record it as a follow-up need rather than solving it here ## Report layering rule For human-facing reading output, keep one authoritative report file. - The detailed report should be the main report. - Intermediate Markdown should only be a staging or audit artifact. - If intermediate Markdown exists, its structured additions should be merged into the main detailed report rather than kept as a second parallel final report. - In the final Project `sources` refresh bundle, prefer intermediate JSON only; do not include intermediate Markdown unless the user explicitly wants audit traces. ## Important constraint ChatGPT canvas should prefer standard-library-safe scripts and source files already placed in `sources`. If PDF rendering, OCR, or local figure extraction has already been done outside ChatGPT, ask the user to upload: - `visual_manifest.json` - extracted page images - intermediate JSON / Markdown Preferred OCR preprocessing order before upload: - `RapidOCR` - `Tesseract + pytesseract` - `EasyOCR` If the local OCR chain is unavailable, upload the rendered page images anyway and let ChatGPT continue with PDF text layer, captions, and nearby blocks. Do not keep OCR lines, OCR block parsing, or figure-analysis confidence in the default final artifacts unless the user explicitly wants OCR audit traces. When a local preprocessing batch is already finished, only upload final artifacts into Project `sources`. Do not upload probe or test-only OCR directories such as `visuals_test` or `visuals_easyocr_probe*`. Prefer a final bundle that contains: - final `visual_manifest.json` - the final `visuals/pages/` directory if the Markdown still references those images - final intermediate JSON - final detailed Markdown / PDF - final PDFs - final comparison tables or graph-seed JSON files - final project directory index JSON / Markdown Before handing the bundle to the next stage, run: - `scripts/validate_detailed_report_structure.py` - `scripts/build_paper_deep_reading_bundle.py` Do not assume ChatGPT can access local files outside Project `sources`. ## Use - `workflow/01_request_sources.md` - `workflow/02_extract_structure.md` - `workflow/03_figure_and_table_analysis.md` - `workflow/04_gap_mining_and_graph.md` - `workflow/05_extended_argument_and_innovation_audit.md` - `workflow/06_teaching_explainer_preparation.md` - `workflow/07_talk_qa_rehearsal.md` - `workflow/08_staged_cartoon_visual_storyboard.md` - `workflow/09_storyboard_pdf_assembly.md` - `scripts/assemble_storyboard_pdf.py` - `schemas/paper_focus_spec.template.json` - `schemas/detailed_report_contract.md` - `schemas/detailed_report_required_sections.json` - `schemas/per_paper_output_layout.md` - `schemas/project_directory_index_spec.md` - `schemas/project_directory_annotations.template.json` - `schemas/motivation_bridge_analysis.md` - `schemas/research_generative_overlay.md` - `schemas/teaching_explanation_overlay.md` - `schemas/teaching_explanation_spec.template.json` - `schemas/external_best_practices_sources.md` - `schemas/routing_status_template.json` - `schemas/sources_zip_layout.md` - `schemas/sources_refresh_templates.md` - `scripts/build_canvas_deepread_intermediate.py` - `scripts/init_paper_deep_reading_scaffold.py` - `scripts/build_paper_deep_reading_bundle.py` - `scripts/validate_detailed_report_structure.py` - `scripts/update_project_directory_index.py` - `scripts/update_routing_status.py` ## Reply footer rule At the end of every substantive reply, append: - `Current Status` - `Possible User Inputs For Next Stage` Do not include a `Recommended Next Skill` section. When visual generation is the likely next action, include a user prompt that explicitly says `生成多张连续的卡通图`. ## Batch Completeness Rule - Deep-read every paper in `metadata/paper_batch_manifest.json`. Do not select-read only part of the batch. - Each paper must produce one authoritative per-paper detailed report plus the expected machine-readable intermediate artifact. - If a paper is from `ICLR`, consume the already-downloaded local OpenReview review / rebuttal bundle instead of skipping review context. - Before handoff, run `scripts/validate_detailed_report_structure.py`. That validator should fail if any paper in the batch still lacks its authoritative report. - The handoff bundle should also include the current status description and the project directory description so the next session can resume from the zip alone. ## Next-Stage Handoff - Optional downstream function, only when the user asks: mine directions and innovation points from authoritative deep-read outputs, then build the graph workspace. - Pass forward from this stage: - `*_detailed_cn.md` - `*_detailed_cn.pdf` - `intermediate/*.json` - visual manifests and final figure-analysis artifacts when available - derivative teaching sidecars under `generated/teaching/` when generated - the refreshed deep-read bundle uploaded back into Project `sources` - `metadata/query_spec.json` - `metadata/paper_batch_manifest.json` - `metadata/delivery_bundle_manifest.json` - `metadata/routing_status.json` - `metadata/project_directory_index.json` - `reports/project_directory_index.md` - `reports/stage_delivery_handoff.md` - the complete refreshed zip bundle uploaded back into Project `sources` - Next-stage user may need to provide: - `research_subfield` or a confirmed direction label - which candidate starting nodes or expansion branches to activate - optional `budget` / `hardware` information before ranking directions - whether the next graph stage should only list unranked candidate directions or produce a ranked priority table - Next stage should reference these state fields first: - `paper_id` - `paper_title` - `key_artifacts` - `blockers` - and consult `metadata/project_directory_index.json` before searching the tree ad hoc

path: BUILD_NOTES_CN.md
content: # 构建说明

- Skill slug: `paper-deepread-comic-studio`
- Display version: `v1.2.0`
- ClawHub semver: `1.2.0`
- License: `MIT-0`（在元数据与文档中声明；未包含无扩展名 LICENSE 文件，以适配 ClawHub 文本文件校验）
- 本版本包含分阶段多张连续卡通图工作流、PDF/LaTeX 双来源生图依据、报告可复现精读要求、最终图像 PDF 合成步骤，以及 ClawHub 发布所需元信息。


path: CHANGES_CN.md
content: # 更新记录

## v1.2.0 - 精读质量与连续多图生图增强版

- 将技能包版本统一为 `v1.2.0`（ClawHub/semver 字段使用 `1.2.0`）。
- 强化精读报告标准：避免泛泛总结，要求解释到可复现、可答辩、可讲给别人听。
- 新增关键概念讲解顺序：`直觉 -> 数学公式或 formal definition -> 具体例子 -> 局限 / failure case`。
- 新增复杂模块细节要求：输入、输出、符号、维度、训练参数、固定超参、训练数据流、推理数据流都要说明。
- 强制区分证据层级：论文明确写明、论文没写但合理推测、参考相近工作推测、缺失 / 未报告。
- 强化实验部分：数据集规模、标签定义、baseline 来源与是否重跑/重构、指标含义、结果例外、消融逻辑和复现风险都要写清楚。
- 要求最后给出完整数字例子，把训练和推理串起来；若只能做 toy simplification，必须明确标注。
- 强化连续卡通图生图提示：每次连续生图必须写明“生成多张连续的卡通图”，考虑运镜、风格一致性、逻辑连续性、前后批次一致性和证据核对。
- 明确不同论文部分必须拆成多张或多批图片，不得压缩合并到一张图中。
- 移除回答页脚中的 `Recommended Next Skill`，只保留状态和下一步用户输入建议。

## v1.1.0 - ClawHub/MIT-0 发布版

### 命名更新

- 技能展示名更新为 `Paper DeepRead Comic Studio`。
- 中文宣传名更新为 `论文精读漫画工坊`。
- Skill slug 更新为 `paper-deepread-comic-studio`。


### ClawHub validation fix

- 移除 `.clawhubignore` 与无扩展名 `LICENSE` 文件，避免 ClawHub 将其判定为 non-text files。
- MIT-0 许可仍在 `SKILL.md` frontmatter、`README.md`、`_meta.json` 与发布页信息中声明。
- 补充 Codex 类环境的生图优先级：若 `imagegen` skill 可用，生图阶段应优先使用 `imagegen` skill；仅当 `imagegen` 不可用或能力不足时，再回退到 ChatGPT Images 2.0 API 或其他用户批准的生图 API。

- 将技能包版本统一为 `v1.1.0`（ClawHub/semver 字段使用 `1.1.0`）。
- 保留完整论文精读、研究生成、教学讲解、答辩准备能力。
- 固化分阶段卡通漫画 storyboard 工作流：首次启动只输出 plan + 完整精读报告，不能生图；后续步骤逐段生成统一风格、连续逻辑的卡通图。
- 明确文字报告与生图不能在同一次回答中混合。
- 明确生图可基于 PDF、LaTeX 源码，或 PDF + LaTeX 交叉核对。
- 明确平台使用方式：ChatGPT 网页版/App 使用 Create image；Codex/Claude Code 等环境优先使用 `imagegen` skill，必要时回退到 ChatGPT Images 2.0 API 或其他可用生图 API；不使用 SVG 替代卡通漫画分镜。
- 新增最终步骤：将所有已确认图像合成为 16:9 PDF。
- 完成 ClawHub 封装：`SKILL.md` YAML frontmatter、`_meta.json`、发布页信息与安全隐私说明；移除无扩展名辅助文件以通过 ClawHub 文本文件校验。
- License: MIT-0。


path: PUBLISHING_CLAWHUB.md
content: # ClawHub Publishing Notes

Skill: `paper-deepread-comic-studio`

Display name: `Paper DeepRead Comic Studio`

中文名: `论文精读漫画工坊`

Display version: `v1.2.0`

ClawHub semver value: `1.2.0`

License: `MIT-0`

## Publish command

```bash
clawhub skill publish ./paper-deepread-comic-studio --version 1.2.0
```

## Package requirements checklist

- `SKILL.md` exists at the skill root.
- `SKILL.md` starts with YAML frontmatter containing `name`, `description`, `license`, and `metadata.openclaw`.
- Version uses semver value `1.2.0` in `_meta.json`, `metadata.openclaw.version`, and the publish command for ClawHub compatibility.
- License is declared as `MIT-0` in metadata and documentation.
- Supporting workflow, schema, and scripts are included.
- No private paper content, generated user reports, or user files are bundled.


path: PUBLISH_PAGE_INFO_CN.md
content: # ClawHub 发布页信息：Paper DeepRead Comic Studio v1.2.0

| 字段 | 内容 |
|---|---|
| Slug | `paper-deepread-comic-studio` |
| Display name | `Paper DeepRead Comic Studio` |
| 中文名 | `论文精读漫画工坊` |
| Version | `v1.2.0` |
| ClawHub semver | `1.2.0` |
| License | `MIT-0` |
| Emoji | 📚🎨 |
| Category | Research / Education / Paper Reading / Cartoon Storyboard / Presentation Visuals |

## 一句话简介

精读论文到可复现、可答辩、可讲解的程度，并将论文背景、方法、实验、局限与未来方向转化为统一风格、运镜连续、证据可追溯的多张卡通分镜图，最后可合成为 16:9 PDF。

## 适合谁使用

- 需要精读论文并准备汇报、答辩、组会或课程讲解的研究者。
- 需要将论文方法、实验、局限和未来方向做成可视化分镜的人。
- 需要把 PDF / LaTeX 中的公式、图表、实验和叙事整理为教学材料的人。

## 核心能力

1. **完整论文精读报告**：先给 plan，再直接显示完整精读报告；关键概念按“直觉 -> 公式 -> 例子 -> 局限”解释。
2. **研究生成分析**：抽取问题、动机、隐藏假设、缺口和可追方向。
3. **教学讲解转化**：输出适合讲给别人听的故事线、公式讲法、图表讲法、Q&A。
4. **分阶段多张连续卡通图生成工作流**：背景缺陷、算法流程、实验部分、局限答辩、未来方向等分步生成，不能压缩合并到一张图里。
5. **PDF/LaTeX 证据对齐**：生图可基于 PDF、LaTeX 源码或二者交叉核对。
6. **最终图像 PDF 合成**：将确认后的连续分镜图按顺序合成为一个 16:9 PDF。

## 重要工作流约束

- 启动 skill 后，第一步只生成文字：plan + 完整精读报告 + 当前状态 + 下一步提问建议，**不能生图**。
- 文字报告和生图不能在同一次回答中混合。
- 生图步骤应分阶段进行，每次只生成一个部分，并拆成多张连续 16:9 卡通图。
- 文本里的生图提示必须考虑运镜、风格一致、逻辑连续、与前面已生成图片的设定一致，并先核对原文和精读报告以避免幻觉。
- ChatGPT 网页版/App 使用 **Create image**。
- Codex / Claude Code / coding-agent 环境优先使用 **`imagegen` skill**；当 `imagegen` 不可用或能力不足时，再使用 **ChatGPT Images 2.0 API** 或其他可用生图 API。
- 不使用 SVG 图替代用户要求的卡通漫画分镜。

## 推荐用户触发语

```text
请使用 Paper DeepRead Comic Studio v1.2.0 精读这篇论文，先不要生图。
```

```text
使用这个skill，根据状态，执行第1步：生成多张连续的卡通图，展示背景、旧方法缺陷、论文问题和灵感来源。
```

```text
使用这个skill，根据状态，执行第2步：生成多张连续的卡通图，展示算法整体流程与各模块。
```

```text
使用这个skill，根据状态，执行第3步：生成多张连续的卡通图，展示实验部分。
```

```text
使用这个skill，根据状态，执行第7步：把所有已确认图片合成为一个16:9 PDF。
```

```text
使用这个skill，根据状态，告知下一步应该问什么。
```

## Search keywords

`paper deep reading`, `paper comic`, `cartoon storyboard`, `visual explainer`, `research paper teaching`, `paper defense`, `PPT illustrations`, `论文精读`, `论文漫画`, `答辩插图`

## Release notes

`v1.2.0` 是增强版 ClawHub/MIT-0 发布版，强化可复现精读、实验细节审计、证据层级标注、训练到推理数字例子，以及多张连续卡通图的运镜、风格、逻辑和前后批次一致性规则。


path: README.md
content: # Paper DeepRead Comic Studio Skill v1.2.0

**中文名：论文精读漫画工坊**

**中文名：论文精读漫画工坊**

A ClawHub-ready MIT-0 skill for rigorous paper deep reading and coherent cartoon-comic storyboard generation, ending with final image-PDF assembly.

## Core workflow

1. **Text-only deep read**: start with a plan, then directly display the full deep-reading report. Do not generate images in this step.
2. **Staged visual storyboards**: generate one coherent cartoon-comic section at a time as multiple separate continuous images, preserving camera movement, style, evidence grounding, and narrative continuity.
3. **Final image-PDF assembly**: combine all confirmed storyboard images into one 16:9 PDF.

## Visual steps

- Step 1: Background, prior-method defects, paper problem, and inspiration.
- Step 2: Algorithm overview and modules.
- Step 3: Experiment section.
- Step 4: Limitations and defense.
- Step 5: Future directions and innovation graph.
- Step 6: Cover, summary, and Q&A backup visuals.
- Step 7: Final image-PDF assembly.

## Source grounding

Storyboard and report content may be grounded in the uploaded PDF, LaTeX source, or both. When both are present, cross-check captions, figures, tables, formulas, and claims. Do not invent missing details. Image prompts must keep paper-explicit facts, reasonable inferences, nearby-work inferences, and missing details separate.

## Platform guidance

- ChatGPT web/app: use **Create image** for cartoon storyboard generation.
- Codex / Claude Code / coding-agent environments: prefer the `imagegen` skill when available. If it is unavailable or insufficient, use **ChatGPT Images 2.0 API** or another approved image-generation API.
- Do not substitute SVG diagrams for the requested cartoon-comic storyboard images.
- For continuous cartoon generation, ask for `生成多张连续的卡通图`; split different paper parts into separate images or batches instead of compressing them into one image.

## Resume prompts

```text
使用这个skill，根据状态，执行第X步：<要执行的阶段>。
```

```text
使用这个skill，根据状态，告知下一步应该问什么。
```

## License

MIT-0


path: SECURITY_PRIVACY.md
content: # Security and privacy notes

This skill is designed for paper reading, report generation, staged visual planning, and local image-PDF assembly.

## Data handling

- The skill should use only user-provided papers, uploaded artifacts, and explicitly approved sources.
- The deep-reading phase must not browse external sources unless the user explicitly requests a retrieval stage or the surrounding platform requires verification.
- The image-generation phase should use only the content already summarized in the report and the user-approved visual plan.
- The final PDF assembly step should combine already-generated images locally and should not call external services.

## API usage

- ChatGPT web/app: use Create image when the user starts an image step.
- Codex / Claude Code / coding-agent environments: prefer the `imagegen` skill when available. If it is unavailable or insufficient, use ChatGPT Images 2.0 API or another user-approved image-generation API.
- Do not embed API keys or credentials in outputs.

## Runtime declarations

This package includes optional Python helper scripts. It declares Python as an optional/alternative binary requirement through `metadata.openclaw.requires.anyBins`.

## License

Published ClawHub skills are released under MIT-0; this package declares MIT-0 in SKILL metadata and documentation and does not add conflicting terms.


path: _meta.json
content: ownerId: kn7fxns1xpr6z67w885my7d7k98506vv
slug: paper-deepread-comic-studio
version: 1.2.0
license: MIT-0
publishedAt: 1777872451642

path: workflow/01_request_sources.md
content: # Step 1: Request Sources

If the next stage needs source files, ask the user to upload one zip bundle into Project `sources`.

Typical required files:

- `papers/main/`
- `reviews/openreview/`
- `supplementary/`
- `generated/visuals/`
- `generated/intermediate/`

Wait for confirmation before continuing.


path: workflow/02_extract_structure.md
content: # Step 2: Extract Structure

Build a paper focus spec with:

- direction-native problems
- adjacent parent-field problems
- broader ML/AI scientific problems
- module-to-problem mapping
- graph node candidates
- graph relation candidates
- related papers
- idea-genesis trace

Do not jump directly from a direction-native problem to a remote ML/AI abstraction when a scientifically meaningful intermediate layer exists.
Prefer a continuous ladder such as `PFL -> FL -> AI/ML`.

Also extract the research-generative structure:

- research equation: `Important Setting + Broken Assumption + Borrowed Tool + New Constraint + Surrogate Mechanism`
- unavailable ideal mechanism `Y` and constructed surrogate `Z`
- valuable field / painful assumption / borrowed tool / unserved setting / blocking constraint / replacement mechanism
- challenge -> failure mode -> design principle -> module -> evidence map
- additive vs closed-loop story judgment
- hidden-assumption-to-new-idea candidates


path: workflow/03_figure_and_table_analysis.md
content: # Step 3: Figure And Table Analysis

For important architecture or model figures, extract:

- purpose
- layout
- block inventory
- flow logic
- figure-to-claim mapping
- what remains unclear or potentially misleading
- reusable design blueprint
- text-to-image prompt blueprint
- multi-image storyboard split plan: which claims belong in separate images rather than one compressed image
- camera/style/logic continuity plan for later continuous cartoon generation
- source-grounding check for every paper-specific visual element

If a LaTeX source is available, also inspect figure environments, captions, labels, nearby explanatory text, and included image paths. Reconstruct the role of important figures even when rendered page images are unavailable. Do not silently skip figures just because the source is `.tex`.

If a PDF source is available, explicitly interpret important figures from the rendered pages as well. Do not stop at saying that a figure exists. Explain the visual structure, how the arrows/blocks/curves should be read, which claim the figure supports, and what remains ambiguous, visually weak, or possibly misleading.

For important tables and charts, extract:

- what question the visual answers
- what the axes / legends / compared conditions mean when applicable
- which claim the table/chart is supposed to support
- whether the data really supports that claim, only partially supports it, or conflicts with it
- likely reasons for any mismatch, anomaly, or controversy
- why the layout is persuasive or potentially misleading
- what can be borrowed later

If page images, LaTeX figure metadata, or visual manifests are missing, return to Step 1 and request them.


path: workflow/04_gap_mining_and_graph.md
content: # Step 4: Gap Mining And Graph

Use:

- limitations
- weak settings
- failure cases
- reviewer concerns
- rebuttal exchanges
- unresolved issues

to extract:

- new scientific problems
- improvement directions
- innovation hooks
- graph node candidates
- graph relation candidates

Use the research-generative weakness conversion rule:

\[
M_i \text{ works if } H_i \Rightarrow \text{new direction: make } M_i \text{ work under } \neg H_i.
\]

For every candidate direction, record:

- the hidden assumption being violated
- why the current method becomes fragile
- the unavailable ideal mechanism that would solve it
- the possible surrogate or new mechanism
- whether the direction is ordinary engineering, cross-domain transfer, or boundary-pushing research


path: workflow/05_extended_argument_and_innovation_audit.md
content: # Step 5: Extended Argument And Innovation Audit

After the baseline deep-read is complete, run an explicit second-pass audit focused on the following:

- title interpretation
- research equation audit: important setting, broken assumption, borrowed tool, new constraint, surrogate mechanism
- unavailable-mechanism audit: what ideal mechanism `Y` is absent, and what replacement `Z` the paper builds
- author-side discovery audit: valuable field, painful assumption, borrowed or emerging tool, unserved setting, blocking constraint, conceptual replacement
- story-construction audit: challenge -> failure mode -> design principle -> module -> evidence
- reverse citation audit: citation cluster -> narrative function -> inherited assumption -> paper modification
- experiments-as-story-evidence audit: claim -> counterfactual -> metric -> stress condition
- reusable story-making pattern audit: replacement story, two-axis empty cell, closed-loop contribution, hidden-assumption-to-new-idea conversion
- author subjectivity audit: where idea, proof strategy, module design, or engineering choices look author-specific rather than objectively forced
- paper-grounded specificity audit: whether the report stays close to the actual formulas, modules, datasets, baselines, figures, and findings instead of abstract generic phrasing
- frequently discussed prior papers and their remaining blanks
- claim-by-claim evidence support
- extra reviewer-lens audit inspired by strong GitHub paper-review skills: novelty, significance, soundness, methodology rigor, reproducibility, results-claims alignment, missing baselines/controls, figure/table clarity, limitation honesty
- baseline genealogy from related work to experiments
- innovation type: incremental, cross-domain, boundary-breaking, or hybrid
- limitations, unresolved questions, failure modes, and structural ceilings
- discipline-boundary crossing and its limits
- fresh follow-up directions and migration opportunities
- which directions may genuinely push a scientific frontier rather than only polish the current setting
- final plain-language story summary

When experiments contain tables, curves, or visual evidence, explain which claims they are meant to support and call out partial support or contradiction explicitly. If a LaTeX source exists, include figure-caption-aware analysis rather than relying only on rendered PDFs.

Prefer explicit judgments over vague praise. When evidence is missing, say so directly.


path: workflow/06_teaching_explainer_preparation.md
content: # Step 6: Teaching-Explainer Preparation

After the full deep-read and research-generative audit, prepare the paper for explanation to another person.

## Inputs

Use only materials already inside the uploaded bundle and the authoritative detailed report draft:

- paper PDF / LaTeX / appendix
- visual manifest / generated page images if available
- OpenReview or rebuttal bundle if available
- intermediate JSON
- the current detailed report draft

Do not reopen external retrieval in this stage. If missing context would improve teaching, record it as a collection-stage gap.

## Procedure

1. Identify the target audience. If not specified, default to a graduate student outside the narrow subfield plus a skeptical reviewer/advisor.
2. Write the 30-second, 3-minute, and 10-minute explanations.
3. Extract the teaching story spine: before -> pain -> broken assumption -> key replacement -> mechanism -> evidence -> caveat -> next idea.
4. Build the prerequisite map: concepts, symbols, task setting, benchmark conventions, and assumptions.
5. Convert central formulas into a formula teaching table.
6. Convert key figures/tables into visual teaching scripts.
7. Convert experiments into question-answer evidence units.
8. Build role-play discussion prompts.
9. Build Q&A and defense bank.
10. Add misunderstanding guardrails and teachback self-test questions.
11. Merge all teaching outputs into the authoritative report.
12. If sidecars are requested or useful, generate them under `generated/teaching/<paper-slug>/` as derivatives of the authoritative report.

## Quality bar

A teaching section passes only if it helps someone explain the paper accurately without hiding:

- the core formula/mechanism;
- the evidence chain;
- the strongest caveat;
- the reviewer concern;
- the future research hook.


path: workflow/07_talk_qa_rehearsal.md
content: # Step 7: Talk And Q&A Rehearsal

Use this step when the user wants to explain the paper in a group meeting, journal club, class, lab meeting, defense, or PPT.

## Talk blueprint

Create a slide/talk blueprint derived from the authoritative detailed report.

Default structure:

1. Motivation: why this paper matters.
2. Problem setting: task, inputs, outputs, constraints.
3. Broken assumption: what prior work needed but the target setting lacks.
4. Core insight: unavailable ideal `Y` and surrogate `Z`.
5. Method overview: one architecture/pipeline figure.
6. Formula walkthrough: one central objective/update/bound.
7. Algorithm toy example: concrete mini-case.
8. Experiments: what each block tests.
9. Evidence audit: what is strongly vs weakly supported.
10. Limitations and reviewer concerns.
11. Future directions and boundary-pushing ideas.
12. Three takeaways.

## Q&A rehearsal

For each likely question:

- classify audience: beginner / peer / advisor / reviewer / practitioner;
- provide an answer;
- cite the report section or paper evidence;
- state confidence;
- state what the paper does not prove.

## Defense rule

Do not over-defend. If the paper lacks evidence, answer with a balanced defense:

```text
The paper supports X through [evidence].
It does not fully establish Y because [missing evidence].
A fair follow-up would test Z.
```


path: workflow/08_staged_cartoon_visual_storyboard.md
content: # Workflow 08 — Staged Cartoon Visual Storyboard Generation

This workflow is optional and starts **only after** the authoritative detailed report has been delivered.

## Separation rule

Text report and image generation must not happen in the same assistant turn.

- Step 0: text-only plan + complete deep-reading report + status + next-step prompts.
- Step 1+: one visual storyboard part per user request, generated as multiple separate continuous cartoon images/cards.
- Final assembly is a separate PDF-packaging step and must not generate new images.

## Platform guidance

In a text-only planning/status turn before image generation, tell the user:

- ChatGPT 网页版 / App: use **Create image**.
- Do not generate SVG diagrams for the cartoon storyboard.
- Codex / Claude Code / coding-agent environments: prefer the `imagegen` skill when it is available. If `imagegen` is unavailable or insufficient, call **ChatGPT Images 2.0 API** or another available image-generation API.

## Source basis for storyboard generation

Storyboard image generation can be based on **PDF**, **LaTeX source**, or both. Make this explicit in the planning/status text when relevant.

Use the following priority rules:

1. **PDF-only input**: use rendered pages, figure/table positions, visible diagrams, captions, axes, numeric tables, and nearby text.
2. **LaTeX-only input**: use `figure`/`table` environments, captions, labels, `\includegraphics` paths, equations, section text, appendix content, and source comments when useful.
3. **PDF + LaTeX input**: cross-check both; use the PDF for rendered visual appearance and LaTeX for exact captions, labels, formulas, figure filenames, and text around visuals.
4. **Authoritative report available**: treat the report as the storyboard's primary planning anchor, but preserve traceability back to PDF/LaTeX evidence.
5. **Conflict or missing detail**: do not invent; mark the item as “PDF/LaTeX 未报告” or ask the user for the missing source in a text-only turn.

Every storyboard step should state, internally or in a visible planning note, which source basis it is using: `PDF`, `LaTeX`, `PDF+LaTeX`, or `report-derived from PDF/LaTeX`.

## Multi-image prompt contract

Whenever a text reply writes a prompt for continuous cartoon generation:

- Require **multiple separate 16:9 images/cards**, ordered as `第1张`, `第2张`, and so on.
- Split different paper parts into different images or batches. Do not compress background, method, experiments, limitations, and future directions into one image.
- Add camera direction for the sequence: establishing shot, medium shot, close-up, zoom-in, pan, cutaway, transition, or final recap as appropriate.
- Preserve a style bible: same protagonist/narrator, color palette, line style, typography, icon language, panel numbering, source tags, and formula/table rendering style.
- For later batches, reuse earlier visual continuity. If earlier images are not in context, restate the last known style and avoid inventing factual continuity.
- Check every paper-specific number, dataset, module, equation, baseline, figure, claim, and limitation against the original PDF/LaTeX and the authoritative report before prompting.
- Mark evidence strength in prompt notes when needed: `paper-explicit`, `report-derived`, `reasonable inference`, `nearby-work inference`, or `missing / not reported`.
- Keep each image teachable: one main idea, readable labels, limited text, clear source grounding, and no unsupported visual claims.

## Default visual steps

1. Background, old-method defects, paper problem, inspiration.
2. Algorithm overview and module-by-module flow.
3. Experiment section: datasets, baselines, metrics, results, ablations, qualitative plots, reproducibility gaps.
4. Limitations and defense / reviewer-QA visuals.
5. Future directions and innovation graph visuals.
6. Cover, summary, and Q&A backup visuals.
7. Final image-PDF assembly: combine all approved storyboard images into one 16:9 PDF. See `workflow/09_storyboard_pdf_assembly.md`.

## Step output expectations

For each visual step, generate a coherent set of 16:9 cartoon-comic images with:

- consistent protagonist / narrator;
- consistent visual style, colors, icon language, panel numbering, and typography;
- clear continuity, camera movement, and left-to-right logic;
- paper-grounded data, equations, tables, or qualitative claims where relevant;
- no unsupported claims beyond the paper/report evidence.

## Stateless prompt reminder

At the end of each text-only status turn, tell the user:

`如果开启新会话或上下文丢失，请说：使用这个skill，根据状态，执行第X步：生成多张连续的卡通图，...。如果不知道下一步怎么问，可以说：使用这个skill，根据状态，告知下一步应该问什么。`


path: workflow/09_storyboard_pdf_assembly.md
content: # Workflow 09 — Final Storyboard Image PDF Assembly

Use this workflow only after the user has approved all storyboard images from the staged visual workflow.

## Goal

Combine all final storyboard images into one paginated 16:9 PDF that can be downloaded, shared, or used as a visual appendix / presentation handout.

## Trigger prompts

Users may ask:

```text
使用这个skill，根据状态，执行最后一步：把所有已经生成的图合成一个PDF。
```

or:

```text
使用这个skill，根据状态，执行第7步：最终图片PDF合成。
```

## Inputs

Collect, in order:

1. image files from Step 1: background / defects / problem / inspiration;
2. image files from Step 2: algorithm overview and modules;
3. image files from Step 3: experiments;
4. image files from optional Step 4: limitations / defense;
5. image files from optional Step 5: future directions;
6. image files from optional Step 6: cover / summary / Q&A backup.

If filenames do not encode order, ask the user for the desired order or infer from visible titles such as `第1幕`, `第2幕`, ... and state the inferred order before assembly.

## Rules

- Do **not** create new storyboard images in this step.
- Do **not** rewrite the full report in this step.
- Preserve each image as a full page with 16:9 aspect ratio.
- Use one image per page unless the user explicitly asks for a contact sheet.
- Add no extra watermarks or unrelated branding.
- If an image is not exactly 16:9, fit it on a 16:9 page without clipping; use white margins if needed.
- Verify the output by reopening or rendering the PDF when the environment supports verification.

## Recommended PDF output

```text
paper_storyboard_all_images.pdf
paper_storyboard_images_and_pdf.zip   # optional handoff bundle
```

## ChatGPT web/app implementation guidance

Use the available file/Python/PDF workflow. A robust approach is:

1. collect image paths;
2. sort by stage and幕 number;
3. use PIL/Pillow to normalize orientation and fit each image onto a 16:9 canvas;
4. save all canvases as a single PDF;
5. provide the PDF link and a short status note.

## Codex / Claude Code / coding-agent implementation guidance

Use `scripts/assemble_storyboard_pdf.py` or an equivalent local implementation with PIL/Pillow or ReportLab.

Example:

```bash
python scripts/assemble_storyboard_pdf.py   --input-dir generated/storyboards/final_images   --output generated/storyboards/paper_storyboard_all_images.pdf
```

## Final response template

After assembly, reply briefly:

```text
已完成最终图片 PDF 合成。

Current Status
- 已将 X 张图按第1幕 -> 第X幕顺序合成为 16:9 PDF。
- 输出：paper_storyboard_all_images.pdf

Possible User Inputs For Next Stage
- 使用这个skill，根据状态，检查PDF顺序和页面标题是否正确。
- 使用这个skill，根据状态，生成多张连续的卡通图，用于PPT封面、总结页和答辩备用页。
```


path: scripts/assemble_storyboard_pdf.py
content: #!/usr/bin/env python3
"""Assemble staged storyboard images into a 16:9 PDF.

This helper is intentionally simple and local-only. It does not call external APIs.
It fits each image onto a 16:9 page without clipping and writes a multi-page PDF.
"""

from __future__ import annotations

import argparse
import re
from pathlib import Path
from typing import Iterable, List

try:
    from PIL import Image, ImageOps
    from PIL import JpegImagePlugin  # noqa: F401 - registers JPEG encoder for PDF export
except ImportError as exc:  # pragma: no cover
    raise SystemExit("Pillow is required: pip install pillow") from exc

IMAGE_EXTS = {".png", ".jpg", ".jpeg", ".webp", ".tif", ".tiff"}


def natural_key(path: Path):
    text = path.name.lower()
    # prefer Chinese storyboard numbers like 第12幕 when present
    nums = [int(n) for n in re.findall(r"第\s*(\d+)\s*幕|(?:^|[_-])(\d+)(?:[_-]|\.)", text) for n in n if n]
    return (nums[0] if nums else 10**9, [int(s) if s.isdigit() else s for s in re.split(r"(\d+)", text)])


def collect_images(input_dir: Path, explicit: Iterable[str] | None = None) -> List[Path]:
    if explicit:
        paths = [Path(p) for p in explicit]
    else:
        paths = [p for p in input_dir.rglob("*") if p.suffix.lower() in IMAGE_EXTS]
    paths = [p for p in paths if p.exists() and p.is_file()]
    return sorted(paths, key=natural_key)


def fit_to_canvas(img: Image.Image, page_size=(1920, 1080), background=(255, 255, 255)) -> Image.Image:
    img = ImageOps.exif_transpose(img).convert("RGB")
    page_w, page_h = page_size
    scale = min(page_w / img.width, page_h / img.height)
    new_w = max(1, int(img.width * scale))
    new_h = max(1, int(img.height * scale))
    resized = img.resize((new_w, new_h), Image.Resampling.LANCZOS)
    canvas = Image.new("RGB", page_size, background)
    x = (page_w - new_w) // 2
    y = (page_h - new_h) // 2
    canvas.paste(resized, (x, y))
    return canvas


def main() -> int:
    parser = argparse.ArgumentParser(description="Assemble storyboard images into a 16:9 PDF.")
    parser.add_argument("--input-dir", type=Path, default=Path("."), help="Directory containing final storyboard images.")
    parser.add_argument("--output", type=Path, required=True, help="Output PDF path.")
    parser.add_argument("images", nargs="*", help="Optional explicit image paths. If supplied, input-dir scan is skipped.")
    parser.add_argument("--page-width", type=int, default=1920, help="Canvas width in pixels, default 1920.")
    parser.add_argument("--page-height", type=int, default=1080, help="Canvas height in pixels, default 1080.")
    args = parser.parse_args()

    images = collect_images(args.input_dir, args.images if args.images else None)
    if not images:
        raise SystemExit("No images found. Provide --input-dir or explicit image paths.")

    pages = []
    for path in images:
        with Image.open(path) as img:
            pages.append(fit_to_canvas(img, (args.page_width, args.page_height)))

    args.output.parent.mkdir(parents=True, exist_ok=True)
    first, rest = pages[0], pages[1:]
    first.save(args.output, save_all=True, append_images=rest, resolution=150)

    print(f"Wrote {args.output} with {len(pages)} pages.")
    for i, p in enumerate(images, 1):
        print(f"{i:02d}: {p}")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())


path: scripts/build_canvas_deepread_intermediate.py
content: from __future__ import annotations

import argparse
import json
from pathlib import Path


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("focus_spec", type=Path)
    parser.add_argument("output_json", type=Path)
    args = parser.parse_args()

    data = json.loads(args.focus_spec.read_text(encoding="utf-8"))
    payload = {
        "paper_id": data.get("paper_id", ""),
        "title": data.get("title", ""),
        "higher_ml_ai_problems": data.get("higher_ml_ai_problems", []),
        "algorithm_ancestry_upper_problems": data.get("algorithm_ancestry_upper_problems", []),
        "algorithm_encountered_problem_upper_problems": data.get("algorithm_encountered_problem_upper_problems", []),
        "field_problems": data.get("field_problems", []),
        "direction_native_problems": data.get("direction_native_problems", []),
        "module_to_problem_map": data.get("module_to_problem_map", []),
        "graph_node_candidates": data.get("graph_node_candidates", []),
        "graph_relation_candidates": data.get("graph_relation_candidates", []),
        "innovation_hooks": data.get("innovation_hooks", []),
        "research_generative_reading": data.get("research_generative_reading", {}),
    }
    args.output_json.parent.mkdir(parents=True, exist_ok=True)
    args.output_json.write_text(json.dumps(payload, ensure_ascii=False, indent=2) + "\n", encoding="utf-8")
    print(args.output_json.resolve())


if __name__ == "__main__":
    main()


path: scripts/build_paper_deep_reading_bundle.py
content: from __future__ import annotations

import argparse
import json
import zipfile
from pathlib import Path


REQUIRED_RELATIVE_PATHS = [
    Path("reports"),
    Path("reports/per_paper"),
    Path("reports/stage_delivery_handoff.md"),
    Path("reports/project_directory_index.md"),
    Path("metadata/query_spec.json"),
    Path("metadata/paper_batch_manifest.json"),
    Path("metadata/delivery_bundle_manifest.json"),
    Path("metadata/routing_status.json"),
    Path("metadata/project_directory_annotations.json"),
    Path("metadata/project_directory_index.json"),
]

REQUIRED_SOURCE_RECORD_FIELDS = [
    "canonical_paper_page_url",
    "conference_paper_url",
    "conference_pdf_url",
    "openreview_forum_url",
    "openreview_pdf_url",
    "arxiv_abs_url",
    "arxiv_pdf_url",
    "arxiv_latex_url",
    "preferred_source_type",
    "preferred_local_source_path",
    "local_latex_dir",
    "local_pdf_path",
    "local_openreview_pdf_path",
    "local_official_pdf_path",
    "local_arxiv_pdf_path",
    "review_bundle_dir",
    "review_digest_path",
    "canonical_review_source_type",
    "retrieval_sources",
    "verification_state",
    "verification_checks",
    "source_acquisition_status",
    "source_stage",
    "artifact_status",
    "review_bundle_completeness",
]

REQUIRED_UPSTREAM_BUNDLE_CONTEXT_FIELDS = [
    "routing_status_json",
    "project_directory_index_json",
    "project_directory_index_md",
    "paper_batch_manifest_json",
    "openreview_rebuttal_digest_json",
    "stage_delivery_handoff_md",
    "delivery_bundle_manifest_json",
]


def load_required_headings() -> list[str]:
    path = Path(__file__).resolve().parents[1] / "schemas" / "detailed_report_required_sections.json"
    payload = json.loads(path.read_text(encoding="utf-8-sig"))
    return [
        str(section.get("heading", "")).strip()
        for section in payload.get("required_sections", [])
        if str(section.get("heading", "")).strip()
    ]


def resolve_relative_path(root: Path, raw: str) -> Path | None:
    raw = str(raw).strip()
    if not raw or raw.lower() == "string" or raw.startswith("[fill"):
        return None
    candidate = Path(raw)
    if candidate.is_absolute():
        return candidate
    return root / candidate


def validate_report_structure(report_path: Path, required_headings: list[str], label: str) -> list[str]:
    errors: list[str] = []
    if not report_path.exists():
        return [f"{label}: missing authoritative report -> {report_path.as_posix()}"]

    text = report_path.read_text(encoding="utf-8-sig")
    for heading in required_headings:
        if heading not in text:
            errors.append(f"{label}: authoritative report is missing required section heading -> {heading}")
    if "[fill" in text:
        errors.append(f"{label}: authoritative report still contains '[fill' placeholders")
    dangling_prompt_bullets = [
        line_no
        for line_no, line in enumerate(text.splitlines(), start=1)
        if line.lstrip().startswith("- ")
        and line.rstrip().endswith((":", "?"))
        and len(line.strip()) <= 120
    ]
    if dangling_prompt_bullets:
        preview = ", ".join(str(n) for n in dangling_prompt_bullets[:12])
        errors.append(f"{label}: authoritative report still contains unfinished prompt bullets at lines {preview}")
    empty_bullets = [
        line_no
        for line_no, line in enumerate(text.splitlines(), start=1)
        if line.strip() in {"-", "*", "- ", "* "}
    ]
    if empty_bullets:
        preview = ", ".join(str(n) for n in empty_bullets[:12])
        errors.append(f"{label}: authoritative report still contains empty bullet placeholders at lines {preview}")
    non_whitespace_chars = len("".join(text.split()))
    if non_whitespace_chars < 5000:
        errors.append(
            f"{label}: authoritative report is too short for a top-conference deepread ({non_whitespace_chars} non-whitespace chars)"
        )
    return errors


def review_context_files_exist(workspace_dir: Path) -> bool:
    review_root = workspace_dir / "inputs" / "review_context"
    return review_root.exists() and any(path.is_file() for path in review_root.rglob("*"))


def validate_focus_spec(workspace_dir: Path, focus_spec_path: Path, label: str) -> list[str]:
    errors: list[str] = []
    if not focus_spec_path.exists():
        return [f"{label}: missing focus_spec_json -> {focus_spec_path.as_posix()}"]

    try:
        payload = json.loads(focus_spec_path.read_text(encoding="utf-8-sig"))
    except Exception as exc:
        return [f"{label}: invalid JSON in focus_spec_json -> {exc}"]

    source_record = payload.get("source_record")
    if not isinstance(source_record, dict):
        errors.append(f"{label}: focus spec is missing source_record")
    else:
        missing = [field for field in REQUIRED_SOURCE_RECORD_FIELDS if field not in source_record]
        if missing:
            errors.append(f"{label}: focus spec source_record is missing fields -> {', '.join(missing)}")
        for field in [
            "preferred_local_source_path",
            "local_latex_dir",
            "local_pdf_path",
            "local_openreview_pdf_path",
            "local_official_pdf_path",
            "local_arxiv_pdf_path",
            "review_bundle_dir",
            "review_digest_path",
        ]:
            resolved = resolve_relative_path(workspace_dir, source_record.get(field, ""))
            if resolved and not resolved.exists():
                errors.append(f"{label}: missing source artifact referenced by source_record.{field} -> {source_record.get(field, '')}")

        venue = str(payload.get("venue", "")).strip().casefold()
        if "iclr" in venue and not review_context_files_exist(workspace_dir):
            review_bundle_dir = resolve_relative_path(workspace_dir, source_record.get("review_bundle_dir", ""))
            if not review_bundle_dir or not review_bundle_dir.exists():
                errors.append(
                    f"{label}: ICLR paper requires a downloaded local OpenReview review/rebuttal bundle"
                )

    upstream_bundle_context = payload.get("upstream_bundle_context")
    if not isinstance(upstream_bundle_context, dict):
        errors.append(f"{label}: focus spec is missing upstream_bundle_context")
    else:
        missing = [field for field in REQUIRED_UPSTREAM_BUNDLE_CONTEXT_FIELDS if field not in upstream_bundle_context]
        if missing:
            errors.append(f"{label}: focus spec upstream_bundle_context is missing fields -> {', '.join(missing)}")

    return errors


def validate_manifest_entries(workspace_dir: Path) -> list[str]:
    errors: list[str] = []
    required_headings = load_required_headings()
    path = workspace_dir / "metadata" / "paper_batch_manifest.json"
    try:
        payload = json.loads(path.read_text(encoding="utf-8-sig"))
    except Exception as exc:
        return [f"invalid JSON in metadata/paper_batch_manifest.json: {exc}"]

    papers = list(payload.get("papers", []))
    if not papers:
        return ["metadata/paper_batch_manifest.json: missing papers"]

    for idx, item in enumerate(papers, start=1):
        label = str(item.get("paper_title", "")).strip() or f"paper-{idx}"
        report_md = resolve_relative_path(workspace_dir, item.get("authoritative_report_md", ""))
        report_pdf = resolve_relative_path(workspace_dir, item.get("authoritative_report_pdf", ""))
        focus_spec = resolve_relative_path(workspace_dir, item.get("focus_spec_json", ""))
        intermediate = resolve_relative_path(workspace_dir, item.get("intermediate_json", ""))

        if not report_md:
            errors.append(f"{label}: missing authoritative_report_md")
        elif not report_md.exists():
            errors.append(f"{label}: missing authoritative_report_md -> {item.get('authoritative_report_md', '')}")
        else:
            errors.extend(validate_report_structure(report_md, required_headings, label))

        if not report_pdf:
            errors.append(f"{label}: missing authoritative_report_pdf")
        elif not report_pdf.exists():
            errors.append(f"{label}: missing authoritative_report_pdf -> {item.get('authoritative_report_pdf', '')}")

        if not focus_spec:
            errors.append(f"{label}: missing focus_spec_json")
        else:
            errors.extend(validate_focus_spec(workspace_dir, focus_spec, label))

        if not intermediate:
            errors.append(f"{label}: missing intermediate_json")
        elif not intermediate.exists():
            errors.append(f"{label}: missing intermediate_json -> {item.get('intermediate_json', '')}")

    return errors


def validate_delivery_manifest(workspace_dir: Path) -> list[str]:
    path = workspace_dir / "metadata" / "delivery_bundle_manifest.json"
    try:
        payload = json.loads(path.read_text(encoding="utf-8-sig"))
    except Exception as exc:
        return [f"invalid JSON in metadata/delivery_bundle_manifest.json: {exc}"]

    errors: list[str] = []
    for field in [
        "stage_name",
        "workspace_root",
        "resume_from_bundle_only_supported",
        "status_artifacts",
        "directory_description_artifacts",
        "authoritative_handoff_artifacts",
    ]:
        if field not in payload:
            errors.append(f"metadata/delivery_bundle_manifest.json: missing field -> {field}")
    for rel in payload.get("status_artifacts", []):
        resolved = resolve_relative_path(workspace_dir, rel)
        if not resolved or not resolved.exists():
            errors.append(f"metadata/delivery_bundle_manifest.json: missing status artifact -> {rel}")
    for rel in payload.get("directory_description_artifacts", []):
        resolved = resolve_relative_path(workspace_dir, rel)
        if not resolved or not resolved.exists():
            errors.append(f"metadata/delivery_bundle_manifest.json: missing directory description artifact -> {rel}")
    for rel in payload.get("authoritative_handoff_artifacts", []):
        resolved = resolve_relative_path(workspace_dir, rel)
        if not resolved or not resolved.exists():
            errors.append(f"metadata/delivery_bundle_manifest.json: missing authoritative artifact -> {rel}")
    return errors


def validate_routing_status(workspace_dir: Path) -> list[str]:
    path = workspace_dir / "metadata" / "routing_status.json"
    try:
        payload = json.loads(path.read_text(encoding="utf-8-sig"))
    except Exception as exc:
        return [f"invalid JSON in metadata/routing_status.json: {exc}"]

    errors: list[str] = []
    for field in [
        "current_stage",
        "resume_from_bundle_only_supported",
        "status_artifacts",
        "directory_description_artifacts",
        "authoritative_handoff_artifacts",
        "key_artifacts",
    ]:
        if field not in payload:
            errors.append(f"metadata/routing_status.json: missing field -> {field}")
    for rel in payload.get("status_artifacts", []):
        resolved = resolve_relative_path(workspace_dir, rel)
        if not resolved or not resolved.exists():
            errors.append(f"metadata/routing_status.json: missing status artifact -> {rel}")
    for rel in payload.get("directory_description_artifacts", []):
        resolved = resolve_relative_path(workspace_dir, rel)
        if not resolved or not resolved.exists():
            errors.append(f"metadata/routing_status.json: missing directory description artifact -> {rel}")
    return errors


def validate_workspace_dir(workspace_dir: Path) -> list[str]:
    errors: list[str] = []
    for rel in REQUIRED_RELATIVE_PATHS:
        if not (workspace_dir / rel).exists():
            errors.append(f"missing required path: {rel.as_posix()}")
    errors.extend(validate_routing_status(workspace_dir))
    errors.extend(validate_delivery_manifest(workspace_dir))
    errors.extend(validate_manifest_entries(workspace_dir))
    return errors


def build_zip(workspace_dir: Path, output_zip: Path) -> dict[str, object]:
    errors = validate_workspace_dir(workspace_dir)
    output_zip.parent.mkdir(parents=True, exist_ok=True)
    with zipfile.ZipFile(output_zip, "w", compression=zipfile.ZIP_DEFLATED) as zf:
        for path in sorted(workspace_dir.rglob("*")):
            if path.is_dir():
                continue
            zf.write(path, arcname=path.relative_to(workspace_dir).as_posix())
    return {
        "workspace_dir": str(workspace_dir.resolve()),
        "output_zip": str(output_zip.resolve()),
        "validation_errors": errors,
    }


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("workspace_dir", type=Path)
    parser.add_argument("output_zip", type=Path)
    args = parser.parse_args()
    print(json.dumps(build_zip(args.workspace_dir, args.output_zip), ensure_ascii=False))


if __name__ == "__main__":
    main()


path: scripts/init_paper_deep_reading_scaffold.py
content: from __future__ import annotations

import argparse
import json
import re
import subprocess
import sys
import zipfile
from pathlib import Path


def slugify(text: str) -> str:
    text = text.lower().strip()
    text = re.sub(r"[^a-z0-9\u4e00-\u9fff]+", "-", text)
    text = re.sub(r"-+", "-", text).strip("-")
    return text or "paper-deep-reading"


def ensure_file(path: Path, content: str) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    if not path.exists():
        path.write_text(content, encoding="utf-8")


def normalize_unique(values: list[str]) -> list[str]:
    result: list[str] = []
    for value in values:
        value = value.strip()
        if value and value not in result:
            result.append(value)
    return result


def template_text(filename: str) -> str:
    path = Path(__file__).resolve().parents[1] / "schemas" / filename
    return path.read_text(encoding="utf-8")


def template_json(filename: str) -> dict:
    return json.loads(template_text(filename))


def build_delivery_manifest(
    workspace_root: Path,
    bundle_zip: str = "",
    authoritative_handoff_artifacts: list[str] | None = None,
) -> dict:
    manifest = template_json("delivery_bundle_manifest.template.json")
    manifest["workspace_root"] = str(workspace_root.resolve())
    manifest["delivery_bundle_zip"] = bundle_zip
    if authoritative_handoff_artifacts is not None:
        manifest["authoritative_handoff_artifacts"] = normalize_unique(authoritative_handoff_artifacts)
    manifest["notes"] = normalize_unique(
        list(manifest.get("notes", []))
        + [
            "Restart contract: downstream callers should read delivery_bundle_manifest, routing_status, stage_delivery_handoff, and project_directory_index before scanning the tree.",
            "A fresh session should be able to continue with only this bundle plus the declared status and directory-description artifacts.",
        ]
    )
    return manifest


def refresh_project_directory_index(workspace_root: Path) -> None:
    script_path = Path(__file__).resolve().parents[1] / "scripts" / "update_project_directory_index.py"
    subprocess.run(
        [
            sys.executable,
            str(script_path),
            str(workspace_root),
            "--default-stage",
            "chatgpt_paper_deep_reading_skill_source",
        ],
        check=True,
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE,
        text=True,
    )


def render_report_stub(paper_title: str, paper_id: str, paper_slug: str, existing_collection_root: str) -> str:
    collection_note = existing_collection_root or "[fill collection root if any]"
    return "\n".join(
        [
            f"# {paper_title} 详细精读",
            "",
            "<!-- 写作要求：不要过于简介，必须紧扣论文本身的具体公式、模块、图表、实验与措辞展开 -->",
            "",
            "## 论文信息",
            "",
            f"- 论文 ID：{paper_id or '[fill paper id]'}",
            f"- 标题：{paper_title}",
            "- 会议 / 年份 / 状态：",
            "- OpenReview / DOI / 主页：",
            "- arXiv / PDF / LaTeX：",
            "- 作者：",
            "- 团队 / 机构线索：",
            f"- 现有 collection root：{collection_note}",
            "- 优先使用的源文件：",
            "- review / rebuttal 来源：",
            "- 当前来源缺口：",
            "",
            "## 论文标题解读",
            "",
            "- 标题关键词逐项解释：",
            "- 标题为什么这样命名：",
            "- 标题与方法、任务设定、主张之间的对应关系：",
            "",
            "## 这篇论文真正解决的是什么",
            "",
            "### 具体问题",
            "",
            "- 论文真正要解决的具体问题：",
            "- 为什么旧 formulation 不够：",
            "",
            "### 更上位的科学问题",
            "",
            "- direction-native problem：",
            "- adjacent parent-field problem：",
            "- broader ML/AI scientific problem：",
            "",
            "### 为什么这不是一个更窄的工程问题",
            "",
            "-",
            "",
            "## 论文中提到的其他论文做了什么、留下了什么空白、与本文是什么关系",
            "",
            "- 反复被提及的关键文献：",
            "- 它们分别解决了什么：",
            "- 它们仍然留下了什么空白：",
            "- 当前论文是继承、对比、融合还是转移了它们：",
            "",
            "## 核心方法到底在干什么",
            "",
            "- 知识依赖顺序（先符号/设定 -> 数据/输入 -> 模型 -> 训练/推理 -> 实验/不足）：",
            "- 核心判断 / 核心直觉：",
            "- 方法结构拆解：",
            "- key modules：",
            "- 关键概念四步解释（直觉 -> 数学公式或 formal definition -> 具体例子 -> 局限）：",
            "- 复杂模块输入/输出/符号/维度/训练参数/固定超参/训练与推理数据流：",
            "- 哪些模块设计更像作者的主观取舍，而不是唯一合理方案：",
            "- training pipeline：",
            "- inference / deployment path：",
            "- optimization objectives：",
            "- communication / system path（如果相关）：",
            "- 关键结构图 / 流程图 / 定性图（来自 PDF 或 LaTeX）的解释：",
            "- 图与主张之间的对应关系：",
            "",
            "## 公式保留与逐式解释",
            "",
            "- 必须保留的关键公式列表：",
            "- 公式 1（原文/等价重写）：",
            "  - 每个符号 / 项的含义：",
            "  - 这个公式在方法中的作用：",
            "  - 它对应算法哪一步：",
            "- 公式 2（原文/等价重写）：",
            "  - 每个符号 / 项的含义：",
            "  - 这个公式在方法中的作用：",
            "  - 它对应算法哪一步：",
            "- 哪些公式只是理论分析对象，哪些公式直接进入实现：",
            "- 哪些公式 / 理论对象的选择可能带有作者主观偏好、建模习惯或证明策略：",
            "",
            "## 具体公式、模块与设计假设的不足及可改进空间",
            "",
            "- 公式层面的不足：",
            "  - 哪些项可能过强、过松、欠识别或欠论证：",
            "  - 哪些地方只是启发式拼接：",
            "  - 哪些公式可能带来优化困难、数值不稳定或额外代价：",
            "- 模块层面的不足：",
            "  - 哪些模块可能冗余、脆弱、难扩展、难复用：",
            "  - 哪些模块与论文声称的科学目标并不完全对齐：",
            "- 关键假设层面的不足：",
            "  - 哪些假设过强、隐藏、仅在特定数据/系统下成立：",
            "- 可以怎么改：",
            "  - 可替代公式 / 目标函数 / 正则项：",
            "  - 可替代模块 / 路径 / 机制：",
            "  - 改进后的潜在 trade-off：",
            "",
            "## 创新点、核心主张与证据逐条核对",
            "",
            "- 创新点 1：",
            "  - 对应主张：",
            "  - 支撑证据类型（理论 / 实验 / 可视化 / rebuttal / narrative）：",
            "  - 支撑强度：",
            "- 创新点 2：",
            "  - 对应主张：",
            "  - 支撑证据类型（理论 / 实验 / 可视化 / rebuttal / narrative）：",
            "  - 支撑强度：",
            "- 哪些主张证据不足或只被间接支持：",
            "",
            "## 这篇论文为什么重要 / 为什么值得被接收",
            "",
            "- scientific significance：",
            "- 它挑战了什么假设 / 保留了什么假设：",
            "- 为什么 reviewer / PC 会 care：",
            "",
            "## 实验是如何被设计出来的",
            "",
            "### 实验目的 / 验证链条 1",
            "",
            "-",
            "",
            "### 实验目的 / 验证链条 2",
            "",
            "-",
            "",
            "### 实验目的 / 验证链条 3",
            "",
            "-",
            "",
            "- 主实验在证明什么：",
            "- 数据集规模、标签定义、划分协议和预处理：",
            "- baseline 来源，以及是否重跑、重构或直接引用：",
            "- 指标含义、适用边界和容易误读之处：",
            "- bridge experiments 在证明什么：",
            "- 哪些 ablation 真正支撑了机制：",
            "- 证据和 claim 之间还差什么：",
            "- 缺失实验细节（硬件、耗时、超参、随机种子、数据划分、计算预算等）：",
            "- headline result 的例外、反常现象和复现风险：",
            "- 比较算法与引言 / 相关工作里的算法是什么关系：",
            "- 哪些实验现象有趣、反常或有争议：",
            "- 关键表格 / 曲线 / 图像分别在说明什么：",
            "- 每个关键图表的坐标轴、图例、比较条件意味着什么：",
            "- 哪些图表真正支持主张，哪些只是部分支持：",
            "- 哪些图表与主张存在张力或不一致，可能原因是什么：",
            "",
            "## 倒推作者怎么想到这个 idea",
            "",
            "- borrowed algorithm lineage：",
            "- 哪些地方更像作者的主观判断、经验偏好、工程取舍或研究风格，而非客观唯一解：",
            "- idea genesis trace：",
            "- 为什么这个想法会自然出现：",
            "- 可能受哪些论文、方法或更高层问题启发：",
            "- related papers worth linking：",
            "",
            "## 研究方程与缺失机制替代",
            "",
            "- 重要设定 Important Setting：",
            "- 被打破的旧假设 Broken Assumption：",
            "- 被借用但不能直接迁移的工具 Borrowed Tool：",
            "- 新约束 New Constraint：",
            "- easier setting 中可用的理想机制 `Y`：",
            "- 本文构造的替代机制 `Z`：",
            "- 为什么 `Z` 可以近似 / 替代 `Y`：",
            "- 研究方程：`A(P) ∩ ¬C ∩ T ∩ M ⇒ Z ≈ Y`：",
            "",
            "## 作者可能如何发现这个方向",
            "",
            "- valuable field：",
            "- painful assumption：",
            "- emerging / borrowed tool：",
            "- unserved setting：",
            "- blocking constraint：",
            "- conceptual replacement：",
            "- 哪些判断有论文文本证据支撑，哪些只是合理推测：",
            "",
            "## 论文故事线如何搭建",
            "",
            "| Challenge | Failure mode | Design principle | Module | Evidence |",
            "|---|---|---|---|---|",
            "|  |  |  |  |  |",
            "",
            "- narrative escalation：",
            "- additive story 还是 closed-loop story：",
            "- 在模块之间流动的核心对象（pseudo-label / generated data / graph consensus / uncertainty / prototype 等）：",
            "- 哪些故事连接仍然脆弱：",
            "",
            "## 模块级作者思路深读",
            "",
            "| Module | Failure fixed | Ideal unavailable solution | Available proxy | Design choice | Hidden assumption | Risk | Future research point |",
            "|---|---|---|---|---|---|---|---|",
            "|  |  |  |  |  |  |  |  |",
            "",
            "## 关键引用的叙事功能与 Citation-to-Module Map",
            "",
            "| Citation cluster | Narrative function | Assumption inherited | How this paper modifies it | Related module |",
            "|---|---|---|---|---|",
            "|  |  |  |  |  |",
            "",
            "## 实验作为故事证据",
            "",
            "| Experiment block | Claim | Counterfactual | Metric | Stress condition | Module justified | Support judgment |",
            "|---|---|---|---|---|---|---|",
            "|  |  |  |  |  |  |  |",
            "",
            "## 可复用的论文造故事模式",
            "",
            "- old success + new reality -> old assumption breaks：",
            "- replacement story：`Y` unavailable, so design `Z`：",
            "- two-axis empty cell：",
            "- closed-loop contribution pattern：",
            "- 这套模式如何迁移到下一篇论文 / 新选题：",
            "",
            "## 从隐藏假设生成新 idea",
            "",
            "| Hidden assumption `H_i` | Why current method needs it | Setting under `¬H_i` | Required new mechanism | Engineering / cross-domain / boundary-pushing | New research question |",
            "|---|---|---|---|---|---|",
            "|  |  |  |  |  |  |",
            "",
            "## 作者主观判断与研究风格关联分析",
            "",
            "- where choices look author-specific：",
            "- objective necessity vs author choice：",
            "- evidence-backed subjective inference：",
            "- author style or research taste signals：",
            "",
            "## 报告具体性要求：必须紧扣论文中的公式、模块、图表、实验与措辞",
            "",
            "- concrete formula / module / dataset / baseline mentions：",
            "- figure / table / experiment specifics：",
            "- theorem object and assumption specificity：",
            "- 避免空泛抽象总结的自检：",
            "",
            "## 审稿人最关注什么",
            "",
            "- concern 1：",
            "- concern 2：",
            "- concern 3：",
            "- concern 4：",
            "",
            "## 额外审稿视角审计（借鉴 GitHub 热门审稿 skill 的 reviewer 关注点）",
            "",
            "- novelty / significance 审计：",
            "- technical soundness / methodology rigor 审计：",
            "- reproducibility / missing details 审计：",
            "- results-claims alignment 审计：",
            "- missing baselines / controls 审计：",
            "- figure / table clarity 与 limitations honesty 审计：",
            "",
            "## 作者是怎么回复的",
            "",
            "- reply 1：",
            "- reply 2：",
            "- reply 3：",
            "",
            "## 审稿人是否认同作者回复",
            "",
            "- meta-review / decision signal：",
            "- 哪些点被解决了：",
            "- 哪些点仍 unresolved：",
            "",
            "## 审稿意见回复覆盖核对",
            "",
            "- concern -> reply -> resolution：",
            "- concern -> reply -> resolution：",
            "- coverage conclusion：",
            "",
            "## 这篇论文最强的地方",
            "",
            "### 强点 1",
            "",
            "-",
            "",
            "### 强点 2",
            "",
            "-",
            "",
            "### 强点 3",
            "",
            "-",
            "",
            "## 这篇论文的弱点 / 不足",
            "",
            "### 弱点 1",
            "",
            "-",
            "",
            "### 弱点 2",
            "",
            "-",
            "",
            "### 弱点 3",
            "",
            "-",
            "",
            "- 未解决问题：",
            "- failure modes / scope limits：",
            "- structural limitations：",
            "- open risks：",
            "",
            "## 作者团队近年的相关延续",
            "",
            "- follow-up papers / repos / lab agenda：",
            "- 哪个 continuation signal 最重要：",
            "",
            "## 从这篇论文出发，最值得突破的未来边界",
            "",
            "### 方向 1",
            "",
            "-",
            "",
            "### 方向 2",
            "",
            "-",
            "",
            "### 方向 3",
            "",
            "-",
            "",
            "- 哪些方向只是工程延展：",
            "- 哪些方向可能真正推动科学边界：",
            "",
            "## 创新类型判断：这是增量创新、交叉创新，还是边界突破",
            "",
            "- 创新类型判断：",
            "- 为什么属于增量 / 交叉 / 边界突破：",
            "- 是否突破了学科或子领域边界：",
            "- 这种判断的局限：",
            "",
            "## 对选题的直接启示",
            "",
            "- borrowable mechanisms：",
            "- next experiments：",
            "- 什么应该进入 graph stage：",
            "",
            "## 可能的新研究方向或新创新点（尤其是可能推动科学边界的方向）",
            "",
            "- 原生延展：",
            "- 交叉迁移：",
            "- 混合路线：",
            "- 高风险高回报想法：",
            "- 哪些方向最可能推动科学边界，以及为什么：",
            "",
            "## 面向讲解的受众画像与讲解目标",
            "",
            "| Audience | What they know | Likely confusion | What to explain first | Math depth | Evidence that convinces them |",
            "|---|---|---|---|---|---|",
            "| 技术读者 / 跨方向研究生 |  |  |  |  |  |",
            "| 审稿人 / 导师 |  |  |  |  |  |",
            "| 初学者 |  |  |  |  |  |",
            "",
            "## 3 层讲解摘要：30 秒 / 3 分钟 / 10 分钟",
            "",
            "### 30 秒版本",
            "",
            "-",
            "",
            "### 3 分钟版本",
            "",
            "- problem -> broken assumption -> key idea -> evidence -> caveat：",
            "",
            "### 10 分钟版本",
            "",
            "- 加入方法模块、关键公式、主要实验、限制：",
            "",
            "## 讲解主线 Story Spine",
            "",
            "- Before this paper：",
            "- Pain / broken assumption：",
            "- Tempting but blocked path：",
            "- Key replacement `Y -> Z`：",
            "- Mechanism：",
            "- Evidence：",
            "- Caveat：",
            "- Next idea：",
            "",
            "## 听众先修知识与概念铺垫",
            "",
            "- 最少需要知道的任务设定：",
            "- 最少需要知道的符号：",
            "- 最少需要知道的数据集 / benchmark / metric：",
            "- 最容易误解的领域惯例：",
            "- 建议讲解顺序：",
            "",
            "## 公式 / 图表 / 实验的讲解脚本",
            "",
            "### 公式讲解表",
            "",
            "| Formula | What problem it solves | Term-by-term meaning | How to say it aloud | Algorithm role | What can go wrong |",
            "|---|---|---|---|---|---|",
            "|  |  |  |  |  |  |",
            "",
            "### 图表讲解表",
            "",
            "| Visual | First thing to point at | Listener confusion risk | Claim supported | What not to overclaim | Verbal explanation |",
            "|---|---|---|---|---|---|",
            "|  |  |  |  |  |  |",
            "",
            "### 实验讲解单元",
            "",
            "- 实验回答的问题：",
            "- 审稿人 / 听众可能的质疑：",
            "- setup / dataset / baseline / metric：",
            "- 如果论文主张成立，预期应该看到什么：",
            "- 实际结果：",
            "- 它证明了什么：",
            "- 它没有证明什么：",
            "",
            "## 板书推导与小例子演示",
            "",
            "- mini-case 设置：",
            "- 输入 / 状态 / 输出：",
            "- Step 1：",
            "- Step 2：",
            "- Step 3：",
            "- 这个例子揭示了什么：",
            "- 简化例子在哪些地方会误导：",
            "",
            "## 角色扮演式讨论问题",
            "",
            "| Role | What this role checks | Discussion question | Expected answer / evidence |",
            "|---|---|---|---|",
            "| Archaeologist | prior-work ancestry |  |  |",
            "| Bug Hunter | rigor / reproducibility / clarity |  |  |",
            "| Researcher | future direction |  |  |",
            "| Industry Practitioner | cost and deployment |  |  |",
            "| Social Impact Assessor | risk and impact |  |  |",
            "| Author Defender | acceptance logic |  |  |",
            "| Teacher | learnability |  |  |",
            "",
            "## 可能被问到的问题与回答证据",
            "",
            "| Question | Audience | Evidence-backed answer | Confidence | What the paper does not prove |",
            "|---|---|---|---|---|",
            "|  | beginner |  |  |  |",
            "|  | peer |  |  |  |",
            "|  | advisor / reviewer |  |  |  |",
            "|  | practitioner |  |  |  |",
            "",
            "## 易误解点与纠偏",
            "",
            "- 论文没有声称：",
            "- 类比在哪些地方会失效：",
            "- 哪个结果不能泛化到未测试设定：",
            "- 哪个模块容易被误认为是全部贡献：",
            "- 哪个 baseline / ablation 容易被过度解读：",
            "- 讲的时候必须主动说出的限制：",
            "",
            "## PPT / 分享稿结构草案",
            "",
            "| Slide | Title | One-sentence point | Visual / formula | Speaker notes | Transition | Likely question |",
            "|---|---|---|---|---|---|---|",
            "| 1 | Why care? |  |  |  |  |  |",
            "| 2 | Problem setting |  |  |  |  |  |",
            "| 3 | Broken assumption |  |  |  |  |  |",
            "| 4 | Core idea |  |  |  |  |  |",
            "| 5 | Method |  |  |  |  |  |",
            "| 6 | Evidence |  |  |  |  |  |",
            "| 7 | Limitations |  |  |  |  |  |",
            "| 8 | Future directions |  |  |  |  |  |",
            "| 9 | Takeaways |  |  |  |  |  |",
            "",
            "## 听众可带走的三句话",
            "",
            "1. ",
            "2. ",
            "3. ",
            "",
            "## 最后一段通俗故事总结",
            "",
            "- 用通俗、生动的语言重述这篇论文：",
            "",
            "## 参考来源",
            "",
            "- primary sources：",
            "- supporting sources：",
            "",
            "<!-- paper-deepread-structured-appendix:start -->",
            "",
            "## 结构化补充附录",
            "",
            "### 上位科学问题定位的三条证据链",
            "",
            "- paper-explicit path：",
            "- borrowed-algorithm ancestry path：",
            "- new-algorithm bottleneck path：",
            "",
            "### 统一后的更高层 AI/ML 问题",
            "",
            "-",
            "",
            "### 借鉴算法所属上位问题",
            "",
            "-",
            "",
            "### 新算法遇到的问题所对应的上位问题",
            "",
            "-",
            "",
            "### 模块到问题、算法与瓶颈的映射",
            "",
            "- module -> problem：",
            "- module -> algorithm lineage：",
            "- module -> bottleneck：",
            "",
            "### 知识图谱节点与关系候选",
            "",
            "- graph node candidates：",
            "- graph relation candidates：",
            "",
            "### 研究方程与缺失机制替代",
            "",
            "- Important Setting + Broken Assumption + Borrowed Tool + New Constraint + Surrogate Mechanism：",
            "- unavailable ideal `Y`：",
            "- surrogate `Z`：",
            "- `Z ≈ Y` 的证据与不足：",
            "",
            "### Challenge-Failure-Module-Evidence 映射",
            "",
            "| Challenge | Failure mode | Design principle | Module | Evidence |",
            "|---|---|---|---|---|",
            "|  |  |  |  |  |",
            "",
            "### Module-Ideal-Proxy-Assumption-New-Idea 映射",
            "",
            "| Module | Unavailable ideal | Available proxy | Hidden assumption | New idea under violated assumption |",
            "|---|---|---|---|---|",
            "|  |  |  |  |  |",
            "",
            "### Citation-to-Module Map",
            "",
            "| Citation cluster | Narrative function | Related module | Inherited assumption | Paper modification |",
            "|---|---|---|---|---|",
            "|  |  |  |  |  |",
            "",
            "### Experiments-As-Story-Evidence Matrix",
            "",
            "| Experiment | Claim | Counterfactual | Metric | Stress condition | Story role |",
            "|---|---|---|---|---|---|",
            "|  |  |  |  |  |  |",
            "",
            "### Reusable Story-Making Pattern",
            "",
            "- replacement story：",
            "- two-axis empty cell：",
            "- closed-loop contribution：",
            "- boundary-pushing template：",
            "",
            "### Hidden-Assumption-To-Boundary-Direction Table",
            "",
            "| Hidden assumption | Violated setting | New mechanism needed | Boundary-pushing potential |",
            "|---|---|---|---|",
            "|  |  |  |  |",
            "",
            "### 提出算法的模型、架构、训练与推理流程",
            "",
            "- model form：",
            "- architecture summary：",
            "- key modules：",
            "- 哪些模块设计更像作者的主观取舍，而不是唯一合理方案：",
            "- training pipeline：",
            "- inference pipeline：",
            "- optimization objectives：",
            "- communication / deployment path：",
            "",
            "### 公式保留与逐式解释",
            "",
            "- preserved equations：",
            "- term-by-term explanation：",
            "- role of each equation：",
            "- equation -> algorithm step mapping：",
            "",
            "### 具体公式、模块与设计假设的不足及可改进空间",
            "",
            "- formula-level weaknesses：",
            "- module-level weaknesses：",
            "- hidden or strong assumptions：",
            "- optimization / efficiency concerns：",
            "- alternative formulations or modules：",
            "- trade-offs of proposed improvements：",
            "",
            "### 带具体例子的算法步骤演示",
            "",
            "- worked example setup：",
            "- step-by-step state updates：",
            "- example inputs / outputs：",
            "- complete numeric training-to-inference walkthrough：",
            "- learned parameters vs fixed hyperparameters：",
            "- what the example reveals：",
            "",
            "### 相关论文与关联理由",
            "",
            "-",
            "",
            "### 论文中反复提到的关键文献及其未解空白",
            "",
            "- key repeatedly discussed papers：",
            "- unsolved gaps carried forward：",
            "- why current paper targets those gaps：",
            "",
            "### 创新点与主张的证据审计表",
            "",
            "- claim row：",
            "- evidence columns：",
            "- support strength：",
            "- missing support notes：",
            "",
            "### 审稿覆盖核对",
            "",
            "- review -> reply chain：",
            "- report-level coverage conclusion：",
            "",
            "### 架构图 / 模型图 / 结果图补充",
            "",
            "- important figures / pages：",
            "- what each visual clarifies：",
            "",
            "### 架构图 / 模型图设计方案",
            "",
            "- reusable figure blueprint：",
            "- visual prompt blueprint：",
            "- multi-image camera/style/logic continuity plan：",
            "- split into multiple images, not one compressed image：",
            "- source grounding and hallucination check：",
            "",
            "### 实验图表设计可借鉴点",
            "",
            "-",
            "",
            "### 实验设置与比较算法谱系对应表",
            "",
            "- datasets / metrics / protocols：",
            "- baseline -> related work mapping：",
            "- why each baseline is included：",
            "- intro / related work -> experiment link：",
            "",
            "### 各实验环节的目的、支撑主张与现象总结",
            "",
            "- experiment block purpose：",
            "- claim supported by each block：",
            "- surprising or controversial findings：",
            "- limitations exposed：",
            "",
            "### 可继续追的创新点",
            "",
            "-",
            "",
            "### Teaching-Explainer Appendix",
            "",
            "- audience map：",
            "- story spine：",
            "- formula / visual / experiment teaching scripts：",
            "- role-play discussion pack：",
            "- Q&A and defense bank：",
            "- slide / talk blueprint：",
            "- teachback self-test：",
            "",
            "<!-- paper-deepread-structured-appendix:end -->",
            "",
            "## Scientific Problem, Missing Gap, And Literature Positioning",
            "",
            "- Which scientific problem should actually be stated at the paper's own level?",
            "- Which scientific gap does the paper claim to fill?",
            "- Which adjacent literature threads are the closest comparators?",
            "- Which older methods or borrowed families does the paper inherit from?",
            "- What exactly is improved over those inherited methods?",
            "- Which blank between prior work and this paper became the real entry point for the contribution?",
            "- Which papers are most directly related, which are only loosely related, and why?",
            "",
            "## Claim-Support Matrix",
            "",
            "- List each major claim as a row.",
            "- List the support sources or evidence types as columns.",
            "- Judge support strength for each row.",
            "- Point out any missing or indirect support.",
            "",
            "## Symbols, Definitions, And Core Concepts For Beginners",
            "",
            "- List the main symbols and what they mean.",
            "- Explain the central definitions and assumptions in beginner-friendly language.",
            "- Explain the task setting, objective, and evaluation concepts with a simple example.",
            "- Explain any problem-specific notation, datasets, protocols, and operators that a beginner would otherwise misread.",
            "",
            "## Core Algorithm And Procedure",
            "",
            "- Give the algorithm step by step.",
            "- Clarify inputs, outputs, intermediate states, and update rules.",
            "- Explain which parts are novel and which parts are inherited baselines.",
            "- State the main computational cost, memory cost, and any deployment-critical path.",
            "",
            "## Algorithm Walkthrough With A Concrete Example",
            "",
            "- Define a mini-case with concrete variables or samples.",
            "- Walk through each step and state update.",
            "- Highlight where the novel part changes the trajectory.",
            "- Explain what this example teaches a beginner.",
            "",
            "## Theory, Proofs, And Their Role",
            "",
            "- What propositions / theorems / lemmas are stated?",
            "- Why did the authors need these proofs?",
            "- Which assumptions are crucial for the proofs?",
            "- What is the proof strategy at a high level?",
            "- Which conclusions actually matter for the practical algorithm?",
            "- Which implementation steps or system behaviors correspond to the proved objects?",
            "- Is the implementation exactly matched to the proof target, only a local approximation, or only theory-motivated?",
            "- What theory-to-algorithm gap still remains?",
            "",
            "## 理论、证明与实现步骤对照",
            "",
            "- theorem / lemma / proposition -> algorithm step mapping：",
            "- assumptions -> implementation assumptions：",
            "- exact match / local approximation / loose motivation：",
            "- why these proofs matter in practice：",
            "- where theory stops matching practice：",
            "",
            "## 具体公式、模块与设计假设的不足及可改进空间",
            "",
            "- formula-level weaknesses：",
            "- module-level weaknesses：",
            "- assumption fragility or mismatch：",
            "- optimization / efficiency concerns：",
            "- possible alternatives or reformulations：",
            "- improvement room and trade-offs：",
            "",
            "## Experimental Design Logic And Author Reasoning",
            "",
            "- Why did the authors choose these datasets, baselines, and metrics?",
            "- Which doubt is each major experiment trying to preempt?",
            "- What sequence of reasoning likely led from the idea to this experiment plan?",
            "- Which experiment exists mainly to convince skeptical reviewers rather than only to improve the scoreboard?",
            "",
            "## Probe Models, Bridge Experiments, And Mechanism Checks",
            "",
            "- Which exploratory models, probes, or pilot experiments help bridge the gap from idea to final algorithm?",
            "- Which mechanism checks are convincing and which are still weak?",
            "- Which failed or partial design paths can be inferred from the final experiment layout?",
            "",
            "## Interesting Empirical Phenomena And Lessons",
            "",
            "- Which surprising or counter-intuitive results appeared?",
            "- What do these phenomena teach us about the scientific problem?",
            "- What should a follow-up paper test next because of these findings?",
            "",
            "## Innovation Type And Boundary-Crossing Judgment",
            "",
            "- Is the work mainly incremental, cross-domain, or boundary-breaking?",
            "- Why does that judgment hold?",
            "- Does it truly cross a disciplinary boundary or mainly recombine ideas within one field?",
            "- Which future crossings or hybridizations does it suggest?",
            "",
            "## Author-Team Continuation Notes From Upstream Materials",
            "",
            "- Which upstream materials already exposed author or team context?",
            "- Which authors can be confirmed from the paper itself or the upstream bundle without reopening search?",
            "- If nearby team continuation context is already present upstream, summarize it here.",
            "- If this context is missing, state that it is deferred back to the collection stage rather than searched here.",
            "",
            "## External Retrieval Deferred To Collection Stage",
            "",
            "- State explicitly that no new external retrieval was performed in this deep-read stage.",
            "- Which missing PDFs, review bundles, author-team context, or related-paper leads should be sent back to the collection stage?",
            "- What stage-boundary note should downstream users keep in mind?",
            "",
            "## Routing Appendix",
            "",
            "Current Status",
            "",
            "- Paper deep-read scaffold initialized.",
            f"- Paper slug: `{paper_slug}`",
            "",
            "Possible User Inputs For Next Stage",
            "",
            "- `使用这个skill，根据状态，继续完成这篇论文的完整精读报告。`",
            "- `使用这个skill，根据状态，执行第1步：生成多张连续的卡通图，展示背景、旧方法缺陷、论文问题和灵感来源。`",
            "- `使用这个skill，根据状态，告知下一步应该问什么。`",
            "",
        ]
    ) + "\n"

def build_focus_spec(paper_title: str, paper_id: str) -> dict:
    payload = template_json("paper_focus_spec.template.json")
    payload["paper_id"] = paper_id
    payload["title"] = paper_title
    payload["related_papers"] = []
    payload["graph_node_candidates"] = []
    payload["graph_relation_candidates"] = []
    payload["innovation_hooks"] = []
    payload["figure_targets"] = []
    payload["research_generative_reading"] = {
        "research_equation": {},
        "author_side_direction_discovery": {},
        "story_construction": {},
        "module_author_thinking": [],
        "reverse_citation_logic": [],
        "experiments_as_story_evidence": [],
        "reusable_story_making_patterns": [],
        "hidden_assumption_to_new_idea": [],
    }
    payload["teaching_explanation_reading"] = {
        "audience_profile": {},
        "three_layer_summary": {},
        "story_spine": {},
        "formula_teaching": [],
        "visual_teaching": [],
        "experiment_teaching": [],
        "role_play_discussion_pack": [],
        "qa_bank": [],
        "misunderstanding_guardrails": [],
        "slide_blueprint": [],
        "teachback_self_test": [],
        "three_takeaways": [],
    }
    return payload


def build_cross_paper_template(paper_titles: list[str]) -> str:
    bullets = "\n".join(f"- {title}" for title in paper_titles)
    return "\n".join(
        [
            "# Cross-Paper Comparison",
            "",
            "## Papers In Scope",
            "",
            bullets or "- [fill papers]",
            "",
            "## Shared Scientific Problems",
            "",
            "-",
            "",
            "## Shared Parent-Field Problems",
            "",
            "-",
            "",
            "## Shared ML/AI Problems",
            "",
            "-",
            "",
            "## Contrasts In Methods And Evidence",
            "",
            "-",
            "",
            "## What Should Enter The Innovation-Graph Stage",
            "",
            "-",
            "",
        ]
    ) + "\n"


def stage_delivery_template(paper_titles: list[str]) -> str:
    paper_lines = "\n".join(f"- {title}" for title in paper_titles)
    return "\n".join(
        [
            "# Stage Delivery Handoff",
            "",
            "## Stage Status",
            "",
            "- Stage: chatgpt_paper_deep_reading_skill_source",
            "- Status: initialized scaffold only; fill every per-paper authoritative report before handoff.",
            "- Deep-read rule: every paper in `metadata/paper_batch_manifest.json` must receive one authoritative detailed report. Selective reading is not allowed at handoff time.",
            "- Downstream contract style: loose coupling, high cohesion. The next stage should read routing status, stage delivery handoff, the paper batch manifest, and the project directory index before scanning directories.",
            "",
            "## Papers Required In This Batch",
            "",
            paper_lines or "- [fill papers]",
            "",
            "## Authoritative Deliverables",
            "",
            "- `metadata/query_spec.json`",
            "- `metadata/paper_batch_manifest.json`",
            "- `metadata/delivery_bundle_manifest.json`",
            "- `metadata/routing_status.json`",
            "- `metadata/project_directory_index.json`",
            "- `reports/stage_delivery_handoff.md`",
            "- `reports/project_directory_index.md`",
            "- `reports/per_paper/<paper-slug>/<paper-slug>_detailed_cn.md`",
            "- `reports/per_paper/<paper-slug>/<paper-slug>_detailed_cn.pdf`",
            "- `generated/intermediate/<paper-slug>.json`",
        ]
    ) + "\n"


def build_zip(workspace_dir: Path, output_zip: Path) -> None:
    output_zip.parent.mkdir(parents=True, exist_ok=True)
    with zipfile.ZipFile(output_zip, "w", compression=zipfile.ZIP_DEFLATED) as zf:
        for path in sorted(workspace_dir.rglob("*")):
            if path.is_dir():
                continue
            zf.write(path, arcname=path.relative_to(workspace_dir).as_posix())


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("label", nargs="?", help="Optional batch label. If no --paper-title is provided, treat this as the single paper title.")
    parser.add_argument("--paper-title", action="append", default=[])
    parser.add_argument("--paper-id", action="append", default=[])
    parser.add_argument("--slug")
    parser.add_argument("--root", type=Path, default=Path("artifacts/paper_deep_reads"))
    parser.add_argument("--existing-collection-root", type=Path)
    parser.add_argument("--research-subfield", default="")
    parser.add_argument("--review-context-note", default="")
    parser.add_argument("--output-mode", choices=["codex_local", "chatgpt_bundle"], default="chatgpt_bundle")
    parser.add_argument("--bundle-zip", type=Path)
    args = parser.parse_args()

    paper_titles = normalize_unique(args.paper_title)
    if not paper_titles and args.label:
        paper_titles = [args.label.strip()]
    if not paper_titles:
        parser.error("Provide at least one --paper-title or a positional label.")

    paper_ids = list(args.paper_id)
    while len(paper_ids) < len(paper_titles):
        paper_ids.append("")

    batch_label = args.label.strip() if args.label else paper_titles[0]
    slug = args.slug or slugify(batch_label)
    root = args.root / slug

    for rel in [
        Path("inputs/papers"),
        Path("inputs/review_context"),
        Path("inputs/source_metadata"),
        Path("metadata"),
        Path("metadata/focus_specs"),
        Path("reports"),
        Path("reports/per_paper"),
        Path("generated/intermediate"),
        Path("generated/visuals"),
    ]:
        (root / rel).mkdir(parents=True, exist_ok=True)

    query_spec = {
        "batch_label": batch_label,
        "paper_titles": paper_titles,
        "research_subfield": args.research_subfield,
        "existing_collection_root": str(args.existing_collection_root.as_posix()) if args.existing_collection_root else "",
        "review_context_note": args.review_context_note,
        "input_contract": {
            "paper_sources": "Upload authoritative PDFs or source folders under inputs/papers/.",
            "review_context": "Upload OpenReview or other review exports under inputs/review_context/ when available.",
            "source_metadata": "Upload manifests, source records, and collection-level directory indexes under inputs/source_metadata/ when available.",
            "restartable_upstream_bundle": "Prefer one previous-stage delivery zip that already carries metadata/delivery_bundle_manifest.json, metadata/routing_status.json, metadata/project_directory_index.json, reports/project_directory_index.md, and reports/stage_delivery_handoff.md.",
        },
        "restartable_handoff_contract": {
            "required_upstream_bundle_artifacts": [
                "metadata/delivery_bundle_manifest.json",
                "metadata/routing_status.json",
                "metadata/project_directory_index.json",
                "reports/project_directory_index.md",
                "reports/stage_delivery_handoff.md",
            ],
            "required_upstream_source_record_fields": list(build_focus_spec("", "").get("source_record", {}).keys()),
            "read_before_browsing_tree": [
                "metadata/delivery_bundle_manifest.json",
                "metadata/routing_status.json",
                "metadata/project_directory_index.json",
                "reports/stage_delivery_handoff.md",
            ],
        },
        "authoritative_report_contract": {
            "contract_file": "schemas/detailed_report_contract.md",
            "required_sections_file": "schemas/detailed_report_required_sections.json",
            "preferred_output_layout_file": "schemas/per_paper_output_layout.md",
        },
        "project_directory_index_outputs": {
            "annotations": "metadata/project_directory_annotations.json",
            "json": "metadata/project_directory_index.json",
            "markdown": "reports/project_directory_index.md",
        },
        "expected_outputs": {
            "per_paper_report_root": "reports/per_paper",
            "intermediate_root": "generated/intermediate",
            "visual_root": "generated/visuals",
            "routing_status_json": "metadata/routing_status.json",
            "stage_delivery_handoff_md": "reports/stage_delivery_handoff.md",
            "delivery_bundle_manifest_json": "metadata/delivery_bundle_manifest.json",
            "delivery_bundle_zip": "outputs/zips/<batch-slug>-paper-deep-reading-bundle.zip",
        },
        "deepread_policy": {
            "read_every_paper_in_batch": True,
            "selective_reading_allowed": False,
            "iclr_review_rule": "when local OpenReview review / rebuttal context exists, consume it in the authoritative report instead of treating it as optional scratch context",
            "upstream_context_reuse_rule": "reuse only author-team or continuation context already present in the upstream bundle or in the paper itself; do not reopen external retrieval here",
            "no_new_external_retrieval_rule": "record retrieval gaps for later collection-stage work instead of starting new academic-site or GitHub search inside deep reading",
        },
    }

    manifest_entries: list[dict[str, object]] = []
    key_artifacts = [
        "metadata/query_spec.json",
        "metadata/paper_batch_manifest.json",
        "metadata/delivery_bundle_manifest.json",
        "metadata/project_directory_index.json",
        "reports/stage_delivery_handoff.md",
        "reports/project_directory_index.md",
    ]

    for paper_title, paper_id in zip(paper_titles, paper_ids):
        paper_slug = slugify(paper_title)
        report_dir = root / "reports" / "per_paper" / paper_slug
        report_md = report_dir / f"{paper_slug}_detailed_cn.md"
        focus_spec_path = root / "metadata" / "focus_specs" / f"{paper_slug}.json"
        ensure_file(report_md, render_report_stub(paper_title, paper_id, paper_slug, str(args.existing_collection_root.as_posix()) if args.existing_collection_root else ""))
        ensure_file(focus_spec_path, json.dumps(build_focus_spec(paper_title, paper_id), ensure_ascii=False, indent=2) + "\n")
        manifest_entries.append(
            {
                "paper_title": paper_title,
                "paper_id": paper_id,
                "paper_slug": paper_slug,
                "authoritative_report_md": str(report_md.relative_to(root).as_posix()),
                "authoritative_report_pdf": f"reports/per_paper/{paper_slug}/{paper_slug}_detailed_cn.pdf",
                "focus_spec_json": str(focus_spec_path.relative_to(root).as_posix()),
                "intermediate_json": f"generated/intermediate/{paper_slug}.json",
                "visual_manifest_json": f"generated/visuals/{paper_slug}/visual_manifest.json",
                "status": "pending_deepread",
            }
        )
        key_artifacts.append(str(report_md.relative_to(root).as_posix()))
        key_artifacts.append(str(focus_spec_path.relative_to(root).as_posix()))

    if len(paper_titles) > 1:
        cross_paper_path = root / "reports" / "cross_paper_comparison_cn.md"
        ensure_file(cross_paper_path, build_cross_paper_template(paper_titles))
        key_artifacts.append(str(cross_paper_path.relative_to(root).as_posix()))

    query_spec_path = root / "metadata" / "query_spec.json"
    query_spec_path.write_text(json.dumps(query_spec, ensure_ascii=False, indent=2) + "\n", encoding="utf-8")
    (root / "metadata" / "paper_batch_manifest.json").write_text(json.dumps({"batch_label": batch_label, "papers": manifest_entries}, ensure_ascii=False, indent=2) + "\n", encoding="utf-8")
    ensure_file(root / "metadata" / "project_directory_annotations.json", template_text("project_directory_annotations.template.json"))

    routing = template_json("routing_status_template.json")
    routing["current_stage"] = "initialized_paper_deep_reading"
    routing["next_stage"] = "awaiting_deepread_execution"
    routing["possible_user_inputs_for_next_stage"] = [
        "使用这个skill，根据状态，继续完成这篇论文的完整精读报告。",
        "使用这个skill，根据状态，执行第1步：生成多张连续的卡通图，展示背景、旧方法缺陷、论文问题和灵感来源。",
        "使用这个skill，根据状态，告知下一步应该问什么。",
    ]
    routing["required_paper_count"] = len(paper_titles)
    routing["remaining_papers_without_authoritative_reports"] = list(paper_titles)
    routing["resume_from_bundle_only_supported"] = True
    routing["status_artifacts"] = [
        "metadata/routing_status.json",
        "reports/stage_delivery_handoff.md",
    ]
    routing["directory_description_artifacts"] = [
        "metadata/project_directory_index.json",
        "reports/project_directory_index.md",
    ]
    routing["last_assistant_action"] = "Initialized the paper deep-reading workspace scaffold."
    routing["paper_id"] = paper_ids[0] if len(paper_titles) == 1 else ""
    routing["paper_title"] = paper_titles[0] if len(paper_titles) == 1 else batch_label
    routing["key_artifacts"] = normalize_unique(key_artifacts)
    routing["authoritative_handoff_artifacts"] = []
    (root / "metadata" / "routing_status.json").write_text(json.dumps(routing, ensure_ascii=False, indent=2) + "\n", encoding="utf-8")
    ensure_file(root / "reports" / "stage_delivery_handoff.md", stage_delivery_template(paper_titles))
    delivery_manifest_artifacts = [
        "metadata/query_spec.json",
        "metadata/paper_batch_manifest.json",
        "metadata/delivery_bundle_manifest.json",
        "metadata/routing_status.json",
        "metadata/project_directory_index.json",
        "reports/stage_delivery_handoff.md",
        "reports/project_directory_index.md",
    ]
    for item in manifest_entries:
        delivery_manifest_artifacts.extend(
            [
                str(item.get("authoritative_report_md", "")).strip(),
                str(item.get("focus_spec_json", "")).strip(),
            ]
        )
    delivery_manifest = build_delivery_manifest(
        root,
        authoritative_handoff_artifacts=delivery_manifest_artifacts,
    )
    routing["authoritative_handoff_artifacts"] = normalize_unique(delivery_manifest_artifacts)
    (root / "metadata" / "routing_status.json").write_text(
        json.dumps(routing, ensure_ascii=False, indent=2) + "\n",
        encoding="utf-8",
    )
    (root / "metadata" / "delivery_bundle_manifest.json").write_text(
        json.dumps(delivery_manifest, ensure_ascii=False, indent=2) + "\n",
        encoding="utf-8",
    )

    refresh_project_directory_index(root)

    bundle_zip = None
    if args.output_mode == "chatgpt_bundle":
        bundle_zip = args.bundle_zip or (Path("outputs/zips") / f"{slug}-paper-deep-reading-bundle.zip")
        build_zip(root, bundle_zip)
        delivery_manifest["delivery_bundle_zip"] = str(bundle_zip.as_posix())
        (root / "metadata" / "delivery_bundle_manifest.json").write_text(
            json.dumps(delivery_manifest, ensure_ascii=False, indent=2) + "\n",
            encoding="utf-8",
        )
        routing["delivery_bundle_zip"] = str(bundle_zip.as_posix())
        (root / "metadata" / "routing_status.json").write_text(
            json.dumps(routing, ensure_ascii=False, indent=2) + "\n",
            encoding="utf-8",
        )

    print(json.dumps({"workspace_root": str(root.resolve()), "query_spec": str(query_spec_path.resolve()), "paper_batch_manifest_json": str((root / "metadata" / "paper_batch_manifest.json").resolve()), "delivery_bundle_manifest_json": str((root / "metadata" / "delivery_bundle_manifest.json").resolve()), "routing_status_json": str((root / "metadata" / "routing_status.json").resolve()), "project_directory_index_json": str((root / "metadata" / "project_directory_index.json").resolve()), "project_directory_index_md": str((root / "reports" / "project_directory_index.md").resolve()), "stage_delivery_handoff_md": str((root / "reports" / "stage_delivery_handoff.md").resolve()), "bundle_zip": str(bundle_zip.resolve()) if bundle_zip else ""}, ensure_ascii=False, indent=2))


if __name__ == "__main__":
    main()


path: scripts/package_clawhub_skill.py
content: #!/usr/bin/env python3
"""Package this skill folder as a ClawHub-ready zip and .skill file."""
from __future__ import annotations

import argparse
import shutil
from pathlib import Path
import zipfile


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("--skill-dir", type=Path, default=Path(__file__).resolve().parents[1])
    parser.add_argument("--out-dir", type=Path, default=Path("dist"))
    parser.add_argument("--slug", default=None)
    parser.add_argument("--version", default=None)
    args = parser.parse_args()

    skill_dir = args.skill_dir.resolve()
    slug = args.slug or skill_dir.name
    version = args.version or "0.0.0"
    out_dir = args.out_dir.resolve()
    out_dir.mkdir(parents=True, exist_ok=True)

    zip_path = out_dir / f"{slug}-v{version}-clawhub.zip"
    skill_path = out_dir / f"{slug}-v{version}.skill"

    ignore = {"__pycache__", ".DS_Store", "dist"}
    with zipfile.ZipFile(zip_path, "w", zipfile.ZIP_DEFLATED) as zf:
        for path in skill_dir.rglob("*"):
            rel = path.relative_to(skill_dir.parent)
            if any(part in ignore for part in rel.parts):
                continue
            if path.suffix.lower() in {".zip", ".pdf", ".png", ".jpg", ".jpeg", ".webp", ".gif", ".pptx", ".docx", ".xlsx"}:
                continue
            if path.is_file():
                zf.write(path, rel.as_posix())

    shutil.copyfile(skill_dir / "SKILL.md", skill_path)
    print(zip_path)
    print(skill_path)
    return 0

if __name__ == "__main__":
    raise SystemExit(main())


path: scripts/update_project_directory_index.py
content: from __future__ import annotations

import argparse
import json
from datetime import datetime
from fnmatch import fnmatch
from pathlib import Path


DEFAULT_OBSOLETE_GLOBS = [
    "**/__pycache__",
    "**/__pycache__/**",
    "**/*.pyc",
    "**/*.pyo",
    "**/*.bak",
    "**/*.tmp",
    "**/*.old",
    "**/*~",
    "**/visuals_test/**",
    "**/*probe*/**"
]

DEFAULT_OBSOLETE_TOKENS = ("obsolete", "deprecated", "discard", "backup", "probe", "tmp", "temp")


def load_json(path: Path | None) -> dict:
    if not path or not path.exists():
        return {}
    return json.loads(path.read_text(encoding="utf-8"))


def rel_path(path: Path, root: Path) -> str:
    return "." if path == root else path.relative_to(root).as_posix()


def match_rule(rel: str, rules: list[dict]) -> dict:
    best: dict = {}
    best_len = -1
    for rule in rules:
        rule_path = str(rule.get("path", "")).strip()
        if rule_path and (rel == rule_path or rel.startswith(f"{rule_path}/")) and len(rule_path) > best_len:
            best = rule
            best_len = len(rule_path)
    return best


def is_obsolete(rel: str, overrides: list[dict]) -> tuple[bool, str]:
    for item in overrides:
        pattern = str(item.get("glob", "")).strip()
        if pattern and fnmatch(rel, pattern):
            return True, str(item.get("notes", "")).strip()
    lowered = rel.casefold()
    if any(token in lowered for token in DEFAULT_OBSOLETE_TOKENS):
        return True, "Heuristic match for temporary or obsolete path naming."
    return False, ""


def infer_purpose(rel: str, kind: str) -> str:
    if rel.endswith("metadata/delivery_bundle_manifest.json"):
        return "Machine-readable restart contract for fresh-session handoff."
    if rel.endswith("metadata/paper_batch_manifest.json"):
        return "Authoritative list of papers that must be completed in this deep-read batch."
    if rel.endswith("metadata/query_spec.json"):
        return "Batch-level input, output, and restart contract for the deep-read stage."
    if rel.endswith("metadata/routing_status.json"):
        return "Current stage status for downstream routing."
    if rel.endswith("metadata/project_directory_index.json"):
        return "Machine-readable directory description for downstream routing."
    if rel.endswith("reports/project_directory_index.md"):
        return "Human-facing directory description for downstream routing."
    if rel.endswith("reports/stage_delivery_handoff.md"):
        return "Human-facing stage delivery note describing authoritative artifacts and next-stage usage."
    if rel.startswith("reports/per_paper/") and rel.endswith("_detailed_cn.md"):
        return "Authoritative per-paper deep-read report."
    if rel.startswith("reports/per_paper/") and rel.endswith("_detailed_cn.pdf"):
        return "Rendered PDF version of the authoritative per-paper deep-read report."
    if rel.startswith("metadata/focus_specs/") and rel.endswith(".json"):
        return "Per-paper structured focus spec carrying source metadata, upstream bundle context, and graph-ready scratch fields."
    if rel.startswith("generated/intermediate/") and rel.endswith(".json"):
        return "Machine-readable per-paper deep-read output for downstream graph construction."
    if rel.startswith("generated/visuals/") and rel.endswith("visual_manifest.json"):
        return "Manifest describing final visual artifacts that remain relevant to the report."
    if rel.startswith("inputs/source_metadata/") and rel.endswith("source_record.json"):
        return "Copied per-paper source record from upstream collection stages."
    if rel.startswith("inputs/review_context/") and rel.endswith("forum.json"):
        return "Copied OpenReview forum metadata used during deep reading."
    if rel.startswith("inputs/review_context/") and rel.endswith("author_responses.md"):
        return "Copied author rebuttal or response summary used during deep reading."
    if rel.startswith("inputs/review_context/") and rel.endswith("decision.json"):
        return "Copied decision or meta-review metadata used during deep reading."
    if rel.startswith("inputs/review_context/") and kind == "directory":
        return "Copied peer-review context required for papers with public review artifacts."
    return ""


def build_entry(path: Path, root: Path, rules: list[dict], overrides: list[dict], default_stage: str) -> dict:
    rel = rel_path(path, root)
    rule = match_rule(rel, rules)
    rule_path = str(rule.get("path", "")).strip()
    obsolete, obsolete_note = is_obsolete(rel, overrides)
    kind = "directory" if path.is_dir() else "file"
    purpose = str(rule.get("purpose", "")).strip()
    notes = str(rule.get("notes", "")).strip()
    status = str(rule.get("status", "active")).strip() or "active"
    inferred_purpose = infer_purpose(rel, kind)
    if obsolete:
        status = "obsolete_or_ignored"
        notes = obsolete_note or notes
    if inferred_purpose and rule_path != rel:
        purpose = inferred_purpose
    if not purpose:
        purpose = "Workspace root." if rel == "." else inferred_purpose or f"Unclassified {kind}."
    return {
        "relative_path": rel,
        "kind": kind,
        "purpose": purpose,
        "generated_by_stage": str(rule.get("generated_by_stage", "")).strip() or default_stage,
        "status": status,
        "notes": notes
    }


def render_markdown(index: dict) -> str:
    def esc(text: str) -> str:
        return text.replace("|", "\\|").replace("\n", " ").strip()

    lines = [
        "# Project Directory Index",
        "",
        "## Summary",
        "",
        f"- workspace root: `{index['workspace_root']}`",
        f"- generated at: `{index['generated_at']}`",
        f"- default stage: `{index['default_stage']}`",
        "",
        "## Entries",
        "",
        "| Path | Kind | Purpose | Generated By Stage | Status | Notes |",
        "| --- | --- | --- | --- | --- | --- |"
    ]
    for entry in index["entries"]:
        lines.append("| " + " | ".join(esc(str(entry[key])) for key in ["relative_path", "kind", "purpose", "generated_by_stage", "status", "notes"]) + " |")
    return "\n".join(lines) + "\n"


def build_index(root: Path, annotations_path: Path, default_stage: str) -> dict:
    annotations = load_json(annotations_path)
    rules = list(annotations.get("rules", []))
    overrides = list(annotations.get("status_overrides", []))
    if not overrides:
        overrides = [{"glob": pattern, "status": "obsolete_or_ignored", "notes": ""} for pattern in DEFAULT_OBSOLETE_GLOBS]
    entries = [
        build_entry(path, root, rules, overrides, annotations.get("default_stage", default_stage) or default_stage)
        for path in [root] + sorted(root.rglob("*"), key=lambda item: rel_path(item, root))
    ]
    return {
        "generated_at": datetime.now().astimezone().isoformat(timespec="seconds"),
        "workspace_root": str(root.resolve()),
        "default_stage": annotations.get("default_stage", default_stage) or default_stage,
        "annotations_file": str(annotations_path.resolve()),
        "summary": {
            "directories": sum(1 for entry in entries if entry["kind"] == "directory"),
            "files": sum(1 for entry in entries if entry["kind"] == "file"),
            "active_entries": sum(1 for entry in entries if entry["status"] == "active"),
            "obsolete_or_ignored_entries": sum(1 for entry in entries if entry["status"] == "obsolete_or_ignored"),
            "staging_entries": sum(1 for entry in entries if entry["status"] == "staging")
        },
        "entries": entries
    }


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("workspace_root", type=Path)
    parser.add_argument("--annotations", type=Path)
    parser.add_argument("--json-out", type=Path)
    parser.add_argument("--md-out", type=Path)
    parser.add_argument("--default-stage", default="")
    args = parser.parse_args()

    workspace_root = args.workspace_root.resolve()
    annotations_path = args.annotations or (workspace_root / "metadata/project_directory_annotations.json")
    json_out = args.json_out or (workspace_root / "metadata/project_directory_index.json")
    md_out = args.md_out or (workspace_root / "reports/project_directory_index.md")
    default_stage = args.default_stage or workspace_root.name

    index = build_index(workspace_root, annotations_path, default_stage)
    json_out.parent.mkdir(parents=True, exist_ok=True)
    md_out.parent.mkdir(parents=True, exist_ok=True)
    json_out.write_text(json.dumps(index, ensure_ascii=False, indent=2) + "\n", encoding="utf-8")
    md_out.write_text(render_markdown(index), encoding="utf-8")
    print(json.dumps({"json_out": str(json_out.resolve()), "md_out": str(md_out.resolve())}, ensure_ascii=False))


if __name__ == "__main__":
    main()


path: scripts/update_routing_status.py
content: from __future__ import annotations

import argparse
import json
from datetime import datetime
from pathlib import Path


def unique_extend(current: list[str], values: list[str]) -> list[str]:
    result = list(current)
    for value in values:
        if value and value not in result:
            result.append(value)
    return result


def load_status(path: Path, template_path: Path) -> dict:
    if path.exists():
        return json.loads(path.read_text(encoding="utf-8"))
    return json.loads(template_path.read_text(encoding="utf-8"))


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("status_file", type=Path)
    parser.add_argument("--current-stage", default="")
    parser.add_argument("--next-stage", default="")
    parser.add_argument("--possible-user-input", action="append", default=[])
    parser.add_argument("--stage-delivery-report", default="")
    parser.add_argument("--delivery-bundle-zip", default="")
    parser.add_argument("--last-user-request", default="")
    parser.add_argument("--last-assistant-action", default="")
    parser.add_argument("--required-paper-count", type=int)
    parser.add_argument("--remaining-paper-without-report", action="append", default=[])
    parser.add_argument("--completed-stage", action="append", default=[])
    parser.add_argument("--routing-tag", action="append", default=[])
    parser.add_argument("--status-artifact", action="append", default=[])
    parser.add_argument("--directory-description-artifact", action="append", default=[])
    parser.add_argument("--authoritative-handoff-artifact", action="append", default=[])
    parser.add_argument("--artifact", action="append", default=[])
    parser.add_argument("--blocker", action="append", default=[])
    args = parser.parse_args()

    template_path = Path(__file__).resolve().parents[1] / "schemas" / "routing_status_template.json"
    data = load_status(args.status_file, template_path)
    data["updated_at"] = datetime.now().astimezone().isoformat(timespec="seconds")
    if args.current_stage:
        data["current_stage"] = args.current_stage
    if args.next_stage:
        data["next_stage"] = args.next_stage
    data["possible_user_inputs_for_next_stage"] = unique_extend(
        data.get("possible_user_inputs_for_next_stage", []), args.possible_user_input
    )
    if args.stage_delivery_report:
        data["stage_delivery_report"] = args.stage_delivery_report
    if args.delivery_bundle_zip:
        data["delivery_bundle_zip"] = args.delivery_bundle_zip
    if args.last_user_request:
        data["last_user_request"] = args.last_user_request
    if args.last_assistant_action:
        data["last_assistant_action"] = args.last_assistant_action
    if args.required_paper_count is not None:
        data["required_paper_count"] = args.required_paper_count
    data["completed_stages"] = unique_extend(data.get("completed_stages", []), args.completed_stage)
    data["routing_tags"] = unique_extend(data.get("routing_tags", []), args.routing_tag)
    data["status_artifacts"] = unique_extend(data.get("status_artifacts", []), args.status_artifact)
    data["directory_description_artifacts"] = unique_extend(
        data.get("directory_description_artifacts", []), args.directory_description_artifact
    )
    data["authoritative_handoff_artifacts"] = unique_extend(
        data.get("authoritative_handoff_artifacts", []), args.authoritative_handoff_artifact
    )
    data["remaining_papers_without_authoritative_reports"] = unique_extend(
        data.get("remaining_papers_without_authoritative_reports", []), args.remaining_paper_without_report
    )
    data["key_artifacts"] = unique_extend(data.get("key_artifacts", []), args.artifact)
    data["blockers"] = unique_extend(data.get("blockers", []), args.blocker)
    args.status_file.parent.mkdir(parents=True, exist_ok=True)
    args.status_file.write_text(json.dumps(data, ensure_ascii=False, indent=2) + "\n", encoding="utf-8")
    print(json.dumps({"status_file": str(args.status_file), "updated_at": data["updated_at"]}, ensure_ascii=False))


if __name__ == "__main__":
    main()


path: scripts/validate_detailed_report_structure.py
content: from __future__ import annotations

import argparse
import json
import sys
from pathlib import Path


def load_required_headings() -> list[str]:
    path = Path(__file__).resolve().parents[1] / "schemas" / "detailed_report_required_sections.json"
    payload = json.loads(path.read_text(encoding="utf-8-sig"))
    return [
        str(section.get("heading", "")).strip()
        for section in payload.get("required_sections", [])
        if str(section.get("heading", "")).strip()
    ]


def is_iclr_report(text: str) -> bool:
    return "ICLR" in text or "iclr" in text


def review_context_files_exist(workspace_dir: Path) -> bool:
    review_root = workspace_dir / "inputs" / "review_context"
    if not review_root.exists():
        return False
    return any(path.is_file() for path in review_root.rglob("*"))


def load_manifest_entries(workspace_dir: Path) -> list[dict]:
    manifest_path = workspace_dir / "metadata" / "paper_batch_manifest.json"
    if not manifest_path.exists():
        return []
    payload = json.loads(manifest_path.read_text(encoding="utf-8-sig"))
    return list(payload.get("papers", []))


def discover_reports(workspace_dir: Path) -> list[Path]:
    manifest_path = workspace_dir / "metadata" / "paper_batch_manifest.json"
    reports: list[Path] = []
    if manifest_path.exists():
        payload = json.loads(manifest_path.read_text(encoding="utf-8-sig"))
        for item in payload.get("papers", []):
            report_md = str(item.get("authoritative_report_md", "")).strip()
            if report_md:
                reports.append(Path(report_md))

    if reports:
        return reports

    reports.extend(sorted((workspace_dir / "reports" / "per_paper").glob("*/*_detailed_cn.md")))
    reports.extend(sorted((workspace_dir / "reports").glob("*_detailed_cn.md")))
    return reports


def validate_report(report_path: Path, required_headings: list[str]) -> list[str]:
    errors: list[str] = []
    if not report_path.exists():
        return [f"missing report: {report_path.as_posix()}"]

    text = report_path.read_text(encoding="utf-8-sig")
    for heading in required_headings:
        if heading not in text:
            errors.append(f"{report_path.as_posix()}: missing required section heading -> {heading}")

    if "[fill" in text:
        errors.append(f"{report_path.as_posix()}: contains scaffold placeholder '[fill'")

    dangling_prompt_bullets = [
        line_no
        for line_no, line in enumerate(text.splitlines(), start=1)
        if line.lstrip().startswith("- ")
        and line.rstrip().endswith((":", "：", "?", "？"))
        and len(line.strip()) <= 120
    ]
    if dangling_prompt_bullets:
        preview = ", ".join(str(n) for n in dangling_prompt_bullets[:12])
        errors.append(f"{report_path.as_posix()}: contains unfinished prompt bullets at lines {preview}")

    empty_bullets = [
        line_no
        for line_no, line in enumerate(text.splitlines(), start=1)
        if line.strip() in {"-", "*", "- ", "* "}
    ]
    if empty_bullets:
        preview = ", ".join(str(n) for n in empty_bullets[:12])
        errors.append(f"{report_path.as_posix()}: contains empty bullet placeholders at lines {preview}")

    non_whitespace_chars = len("".join(text.split()))
    if non_whitespace_chars < 5000:
        errors.append(
            f"{report_path.as_posix()}: report is too short for a top-conference deepread ({non_whitespace_chars} non-whitespace chars)"
        )

    return errors


def validate_report_with_workspace(workspace_dir: Path, report_path: Path, required_headings: list[str]) -> list[str]:
    errors = validate_report(report_path, required_headings)
    if not report_path.exists():
        return errors

    text = report_path.read_text(encoding="utf-8-sig")
    if is_iclr_report(text) and not review_context_files_exist(workspace_dir):
        errors.append(
            f"{report_path.as_posix()}: ICLR paper requires downloaded OpenReview review/rebuttal files under inputs/review_context/"
        )

    return errors


def validate_manifest_coverage(workspace_dir: Path) -> list[str]:
    errors: list[str] = []
    entries = load_manifest_entries(workspace_dir)
    if not entries:
        return errors

    for idx, item in enumerate(entries, start=1):
        label = str(item.get("paper_title", "")).strip() or f"paper-{idx}"
        report_md = str(item.get("authoritative_report_md", "")).strip()
        if not report_md:
            errors.append(
                f"{label}: missing authoritative_report_md in metadata/paper_batch_manifest.json; every batch paper must have one authoritative detailed report"
            )
            continue
        report_path = Path(report_md)
        resolved = report_path if report_path.is_absolute() else workspace_dir / report_path
        if not resolved.exists():
            errors.append(
                f"{label}: authoritative detailed report is missing -> {report_md}; selective reading is not allowed for handoff"
            )
    return errors


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("workspace_dir", type=Path)
    parser.add_argument("--report", type=Path)
    args = parser.parse_args()

    required_headings = load_required_headings()
    manifest_errors = validate_manifest_coverage(args.workspace_dir)
    reports = [args.report] if args.report else discover_reports(args.workspace_dir)
    if not reports:
        payload = {
            "workspace_dir": str(args.workspace_dir.resolve()),
            "validated_reports": [],
            "validation_errors": manifest_errors + ["no authoritative detailed reports found"],
        }
        print(json.dumps(payload, ensure_ascii=False, indent=2))
        sys.exit(1)

    errors: list[str] = list(manifest_errors)
    for report in reports:
        report_path = report if report.is_absolute() else args.workspace_dir / report
        errors.extend(validate_report_with_workspace(args.workspace_dir, report_path, required_headings))

    payload = {
        "workspace_dir": str(args.workspace_dir.resolve()),
        "validated_reports": [str((r if r.is_absolute() else args.workspace_dir / r).resolve()) for r in reports],
        "validation_errors": errors,
    }
    print(json.dumps(payload, ensure_ascii=False, indent=2))
    if errors:
        sys.exit(1)


if __name__ == "__main__":
    main()


path: schemas/claim_support_audit.template.json
content: {
  "paper_id": "",
  "paper_title": "",
  "claims": [
    {
      "claim_id": "claim_1",
      "claim_text": "",
      "innovation_point": "",
      "evidence_types": [],
      "evidence_locations": [],
      "support_strength": "strong|medium|weak|missing",
      "notes": ""
    }
  ],
  "overall_judgment": {
    "best_supported_claims": [],
    "weakest_supported_claims": [],
    "overclaim_risk": "",
    "innovation_type": "incremental|cross_domain|boundary_breaking|hybrid"
  }
}

path: schemas/delivery_bundle_manifest.template.json
content: {
  "stage_name": "chatgpt_paper_deep_reading_skill_source",
  "resume_from_bundle_only_supported": true,
  "workspace_root": "",
  "delivery_bundle_zip": "",
  "status_artifacts": [
    "metadata/routing_status.json",
    "reports/stage_delivery_handoff.md"
  ],
  "directory_description_artifacts": [
    "metadata/project_directory_index.json",
    "reports/project_directory_index.md"
  ],
  "authoritative_handoff_artifacts": [
    "metadata/query_spec.json",
    "metadata/paper_batch_manifest.json",
    "metadata/delivery_bundle_manifest.json",
    "metadata/routing_status.json",
    "metadata/project_directory_index.json",
    "reports/stage_delivery_handoff.md",
    "reports/project_directory_index.md"
  ],
  "next_stage": {
    "optional_downstream_note": "Only route to graph mining, presentation, or another downstream workflow when the user explicitly asks.",
    "possible_user_inputs_for_next_stage": [
      "使用这个skill，根据状态，告知下一步应该问什么。",
      "使用这个skill，根据状态，执行第1步：生成多张连续的卡通图，展示背景、旧方法缺陷、论文问题和灵感来源。",
      "使用这个skill，根据状态，执行第2步：生成多张连续的卡通图，展示算法整体流程与各模块解释。"
    ],
    "next_stage_should_read_first": [
      "metadata/delivery_bundle_manifest.json",
      "metadata/routing_status.json",
      "metadata/project_directory_index.json",
      "reports/stage_delivery_handoff.md"
    ]
  },
  "notes": [
    "v1.2.0 adds deep explanation, reproducibility, and multi-image cartoon continuity guardrails; optional teaching sidecars remain derivatives and do not replace the authoritative report."
  ],
  "optional_derivative_artifacts": [
    "generated/teaching/<paper-slug>/teaching_outline_cn.md",
    "generated/teaching/<paper-slug>/slide_blueprint_cn.json",
    "generated/teaching/<paper-slug>/qa_bank_cn.json",
    "generated/teaching/<paper-slug>/role_play_discussion_pack_cn.md"
  ]
}


path: schemas/detailed_report_contract.md
content: # Detailed Report Contract

Produce one authoritative detailed report per paper.

Preferred paths inside the uploaded or regenerated bundle:

- `reports/per_paper/<paper-slug>/<paper-slug>_detailed_cn.md`
- `reports/per_paper/<paper-slug>/<paper-slug>_detailed_cn.pdf`

Legacy-compatible fallback:

- `reports/<paper-slug>_detailed_cn.md`
- `reports/<paper-slug>_detailed_cn.pdf`

The detailed report must be at least as rich as the accepted-paper examples under:

- `E:/论文调研/reports/accepted_papers/*.md`

and must also include the additional graph-ready and direction-mining items required by this stage.

## Teaching-Explanation Mandatory Overlay

In addition to all sections below, the report must explicitly include a teaching-explainer layer. This layer is not a replacement for technical depth; it is a second pass that turns the same evidence into an explanation another person can understand, discuss, and challenge.

Minimum teaching-explainer outputs:

- `面向讲解的受众画像与讲解目标`: identify the default or user-specified audience, likely confusions, prerequisite concepts, math depth, and evidence needed.
- `3 层讲解摘要：30 秒 / 3 分钟 / 10 分钟`: provide three talk lengths without losing the central caveat.
- `讲解主线 Story Spine`: before -> pain -> broken assumption -> key replacement -> mechanism -> evidence -> caveat -> next idea.
- `听众先修知识与概念铺垫`: define the task, notation, assumptions, datasets, benchmarks, and field conventions needed before the method makes sense.
- `公式 / 图表 / 实验的讲解脚本`: say how to explain core formulas, visuals, and experiment blocks aloud.
- `板书推导与小例子演示`: walk through at least one central formula/update/mechanism with a concrete mini-case.
- `角色扮演式讨论问题`: build prompts for Archaeologist, Bug Hunter, Researcher, Industry Practitioner, Social Impact Assessor, Author Defender, and Teacher roles.
- `可能被问到的问题与回答证据`: create a Q&A bank for beginner, peer, advisor/reviewer, and practitioner questions.
- `易误解点与纠偏`: state what the paper does not claim, which analogy can mislead, and which result should not be overgeneralized.
- `PPT / 分享稿结构草案`: provide a slide/talk blueprint as a derivative of the authoritative report.
- `听众可带走的三句话`: three accurate takeaways.

If any teaching simplification conflicts with the rigorous reading, include the simplification and then immediately state its limits.

## Research-Generative Mandatory Overlay

In addition to all sections below, the report must explicitly include a research-generative reading layer. This layer is not a replacement for formula preservation, proof explanation, experiment analysis, reviewer audit, or graph-ready appendices; it is an extra idea-generation pass.

Minimum research-generative outputs:

- `研究方程与缺失机制替代`: express the paper as `Important Setting + Broken Assumption + Borrowed Tool + New Constraint + Surrogate Mechanism`, then identify the unavailable ideal mechanism `Y` and the constructed replacement `Z`.
- `作者可能如何发现这个方向`: reconstruct a plausible author-side discovery chain: valuable field, painful assumption, emerging tool, unserved setting, blocking constraint, replacement mechanism.
- `论文故事线如何搭建`: map challenge -> failure mode -> design principle -> module -> evidence, and judge whether the method is additive or closed-loop.
- `模块级作者思路深读`: for each key module, record failure, ideal unavailable solution, available proxy, design choice, hidden assumption, risk, and future research point.
- `关键引用的叙事功能与 Citation-to-Module Map`: explain why key citations appear as narrative functions, not merely as bibliography.
- `实验作为故事证据`: read each experiment as claim + counterfactual + metric + stress condition.
- `可复用的论文造故事模式`: extract the reusable paper-making pattern taught by the paper.
- `从隐藏假设生成新 idea`: convert hidden assumptions and fragile proxy mechanisms into concrete new research ideas, with boundary-pushing directions separated from ordinary engineering follow-up.

If any of these overlaps with an existing section, keep both lenses: the original deep-reading lens explains what the paper did and whether it is well supported; the research-generative lens explains how the paper could have been invented and how to generate the next paper from its fragile assumptions.

## Top-Conference Deepread Rule

The main body must explicitly cover the same kinds of sections that already appear in:

- `E:/论文调研/reports/accepted_papers/CoLoRA_detailed_cn.md`
- `E:/论文调研/reports/accepted_papers/FedDAG_detailed_cn.md`
- `E:/论文调研/reports/accepted_papers/LPSFed_detailed_cn.md`
- `E:/论文调研/reports/accepted_papers/pFedMMA_detailed_cn.md`

Do not stop at a short summary plus a graph appendix.
The authoritative report has two layers:

1. a top-conference-grade main narrative
2. a stage-specific structured appendix for graph building and innovation mining

The report should also be useful at four reading depths:

1. beginner depth: symbols, definitions, and setting are explained without assuming prior familiarity
2. reviewer depth: the report reconstructs what scientific gap is claimed, what evidence supports it, and where the paper still looks weak
3. downstream-builder depth: the report states literature relations, borrowed method families, exact improvements, proof roles, and graph-ready takeaways explicitly
4. innovation-auditor depth: the report judges claim support, innovation type, boundary crossing, and plausible future research directions explicitly
5. teaching-explainer depth: the report can be turned into a talk, Q&A, role-play discussion, and slide blueprint without losing rigorous caveats

## v1.2.0 Deep Explanation And Reproducibility Rule

The report must explain the paper deeply enough that the reader can reproduce the core method, defend it in a skeptical discussion, and teach it to someone else. Do not write broad generic summaries when the paper contains concrete symbols, formulas, modules, figures, data, or experimental protocols.

Use this order unless the paper's own structure makes a different dependency order clearer:

1. symbols, definitions, assumptions, labels, and task setting
2. data, inputs, preprocessing, and source evidence
3. model and modules
4. training objectives, trainable parameters, hyperparameters, and data flow
5. inference/deployment path and outputs
6. experiments, exceptions, reproducibility risks, and limitations

Every key concept must be explained as:

```text
直觉 -> 数学公式或 formal definition -> 具体例子 -> 局限 / failure case
```

Every complex module must state input, output, symbols, dimensions, trainable parameters, fixed hyperparameters, objective terms, training-time data flow, inference-time data flow, and what fails without the module.

Strictly separate evidence levels:

- `论文明确写明`: directly stated in the paper/PDF/LaTeX/rebuttal source.
- `论文没写但合理推测`: inferred from formulas, algorithm structure, tables, or surrounding text.
- `参考相近工作推测`: inferred from standard practice in cited or neighboring methods.
- `缺失 / 未报告`: not available in the provided sources.

When details are missing, list the gap instead of inventing it. This includes hardware, runtime, memory, optimizer, learning rate, seeds, early stopping, hyperparameter search, data split, label definition, preprocessing, baseline source, whether baselines were rerun or reconstructed, code availability, and compute budget.

The experiment section must include dataset scale, label definition, split protocol, baseline genealogy, whether baselines were rerun/reconstructed/imported, metric meanings, headline results, exceptions, ablation interpretation, qualitative evidence, and reproduction risk.

The technical explanation must include a complete numeric toy example that connects training and inference. Define tiny inputs, run the method through at least one training update or loss computation, identify which parameters are learned, then show one inference pass. If the paper does not provide enough detail, mark the example as simplified and state which parts are not paper-explicit.

## Figure And Experiment Evidence Rule

Do not skip figure interpretation. Whether the source is PDF or LaTeX, the report must explicitly explain important architecture figures, pipeline figures, qualitative examples, tables, charts, and curves. For each important visual, state:

- what it is trying to show
- which claim or sub-claim it is supposed to support
- whether the visual evidence really supports that claim, only partially supports it, or conflicts with it
- what remains unclear, visually misleading, or under-explained
- plausible reasons for any mismatch between the visual/data evidence and the paper's stated claims


The detailed report length is not capped. When the paper is dense, controversial, or theoretically layered, prefer a longer report rather than compressing away the reasoning chain.

The report must preserve and explain key formulas, key figures from both PDF and LaTeX sources, and the theory-to-practice relation instead of compressing them away.

The report must preserve key formulas instead of paraphrasing them away. When theory is present, the report must explain why the proof exists, what practical concern it addresses, and whether the implemented method is identical to the proved object, a local approximation, or only loosely motivated by it.

The report should also import extra reviewer concerns from strong GitHub paper-review / peer-review skills as an auxiliary audit target: novelty, significance, soundness, methodology rigor, reproducibility, results-claims alignment, missing baselines or controls, figure/table clarity, and honest limitation disclosure. When LaTeX sources are available, important figures must still be explained via figure environments, captions, labels, and referenced text rather than being silently skipped. The experiment section must explicitly explain key tables, curves, charts, and numeric comparisons, check whether they support the paper's claims, and analyze any inconsistency or partial mismatch.

## Mandatory Section Order

1. 论文信息
2. 论文标题解读
3. 这篇论文真正解决的是什么
4. 论文中提到的其他论文做了什么、留下了什么空白、与本文是什么关系
5. 核心方法到底在干什么
6. 公式保留与逐式解释
7. 具体公式、模块与设计假设的不足及可改进空间
8. 创新点、核心主张与证据逐条核对
9. 这篇论文为什么重要 / 为什么值得被接收
10. 实验是如何被设计出来的
11. 倒推作者怎么想到这个 idea
12. 研究方程与缺失机制替代
13. 作者可能如何发现这个方向
14. 论文故事线如何搭建
15. 模块级作者思路深读
16. 关键引用的叙事功能与 Citation-to-Module Map
17. 实验作为故事证据
18. 可复用的论文造故事模式
19. 从隐藏假设生成新 idea
20. 作者主观判断与研究风格关联分析
21. 报告具体性要求：必须紧扣论文中的公式、模块、图表、实验与措辞
22. 审稿人最关注什么
23. 额外审稿视角审计（借鉴 GitHub 热门审稿 skill 的 reviewer 关注点）
24. 作者是怎么回复的
25. 审稿人是否认同作者回复
26. 审稿意见回复覆盖核对
27. 这篇论文最强的地方
28. 这篇论文的弱点 / 不足
29. 作者团队近年的相关延续
30. 从这篇论文出发，最值得突破的未来边界
31. 创新类型判断：这是增量创新、交叉创新，还是边界突破
32. 对选题的直接启示
33. 可能的新研究方向或新创新点（尤其是可能推动科学边界的方向）
34. 面向讲解的受众画像与讲解目标
35. 3 层讲解摘要：30 秒 / 3 分钟 / 10 分钟
36. 讲解主线 Story Spine
37. 听众先修知识与概念铺垫
38. 公式 / 图表 / 实验的讲解脚本
39. 板书推导与小例子演示
40. 角色扮演式讨论问题
41. 可能被问到的问题与回答证据
42. 易误解点与纠偏
43. PPT / 分享稿结构草案
44. 听众可带走的三句话
45. 最后一段通俗故事总结
46. 参考来源
47. 结构化补充附录
48. Routing Appendix

## Structured Appendix Minimum

Inside `结构化补充附录`, include at least:

- 上位科学问题定位的三条证据链
- 统一后的更高层 AI/ML 问题
- 借鉴算法所属上位问题
- 新算法遇到的问题所对应的上位问题
- 模块到问题、算法与瓶颈的映射
- 知识图谱节点与关系候选
- 提出算法的模型、架构、训练与推理流程
- 关键概念的直觉 -> 数学公式 -> 具体例子 -> 局限解释
- 复杂模块的输入、输出、符号、维度、训练参数和数据流
- 公式保留与逐式解释
- 理论、证明与实现步骤对照
- 具体公式、模块与设计假设的不足及可改进空间
- 相关论文与关联理由
- 论文中反复提到的关键文献及其未解空白
- 创新点与主张的证据审计表
- 符号、定义与核心概念入门解释
- 带具体例子的算法步骤演示
- 完整数字例子：训练和推理串联
- 实验设置与比较算法谱系对应表
- 各实验环节的目的、支撑主张与现象总结
- 实验细节、例外结果与复现风险清单
- 借鉴 GitHub 热门审稿 skill 的额外审稿视角审计
- 创新类型与学科边界判断
- 审稿覆盖核对
- 架构图 / 模型图 / 结果图补充（含 LaTeX figure 环境解释）
- 架构图 / 模型图设计方案
- 实验图表设计可借鉴点
- 可继续追的创新点
- 研究方程与缺失机制替代
- challenge -> failure mode -> design principle -> module -> evidence 映射
- module -> unavailable ideal -> available proxy -> hidden assumption -> new idea 映射
- Citation-to-Module Map
- experiments-as-story-evidence matrix
- reusable story-making pattern
- hidden-assumption-to-boundary-direction table
- teaching story spine
- audience prerequisite map
- formula / visual / experiment teaching scripts
- role-play discussion prompts
- Q&A and defense bank
- slide / talk blueprint
- teachback self-test

## 新增刚性要求（作者主观关联与具体性）

- 在介绍 idea、理论证明、具体算法或模块时，若这些设计明显带有作者的主观判断、经验偏好、启发式选择、研究风格或工程取舍，应显式指出，并区分“客观上必须如此”与“作者选择这样做”。
- 报告不得停留在空泛抽象层面。必须结合论文本身的具体公式、符号、模块名、假设、数据集、baseline、图表、定理对象、实验现象与原文措辞做展开说明。
- 当推测作者主观动机时，要区分有文本证据支撑的判断与基于研究史/写作风格的合理推测。


path: schemas/detailed_report_required_sections.json
content: {
  "schema_version": "v1.2.0-deep-explanation-continuity",
  "authoritative_report_patterns": [
    "reports/per_paper/<paper-slug>/<paper-slug>_detailed_cn.md",
    "reports/<paper-slug>_detailed_cn.md",
    "idea / 理论证明 / 具体算法或模块里哪些部分更像作者的主观选择、经验判断或研究风格"
  ],
  "top_conference_common_sections": [
    "论文信息",
    "这篇论文真正解决的是什么",
    "核心方法到底在干什么",
    "具体公式、模块与设计假设的不足及可改进空间",
    "这篇论文为什么重要 / 为什么值得被接收",
    "实验是如何被设计出来的",
    "倒推作者怎么想到这个 idea",
    "研究方程与缺失机制替代",
    "作者可能如何发现这个方向",
    "论文故事线如何搭建",
    "模块级作者思路深读",
    "关键引用的叙事功能与 Citation-to-Module Map",
    "实验作为故事证据",
    "可复用的论文造故事模式",
    "从隐藏假设生成新 idea",
    "作者主观判断与研究风格关联分析",
    "报告具体性要求：必须紧扣论文中的公式、模块、图表、实验与措辞",
    "审稿人最关注什么",
    "作者是怎么回复的",
    "审稿人是否认同作者回复",
    "审稿意见回复覆盖核对",
    "这篇论文最强的地方",
    "额外审稿视角审计（借鉴 GitHub 热门审稿 skill 的 reviewer 关注点）",
    "这篇论文的弱点 / 不足",
    "作者团队近年的相关延续",
    "从这篇论文出发，最值得突破的未来边界",
    "对选题的直接启示",
    "最后一段通俗故事总结",
    "参考来源",
    "结构化补充附录",
    "Author-Team Continuation Notes From Upstream Materials",
    "External Retrieval Deferred To Collection Stage",
    "Routing Appendix",
    "idea / 理论证明 / 具体算法或模块里哪些部分更像作者的主观选择、经验判断或研究风格"
  ],
  "required_sections": [
    {
      "id": "paper_identity_and_sources",
      "heading": "论文信息",
      "required_items": [
        "title",
        "venue_year_status",
        "openreview_or_primary_urls",
        "arxiv_pdf_or_latex",
        "authors",
        "team_or_affiliation_clues",
        "preferred_local_source_path",
        "review_rebuttal_context",
        "source_basis_and_gaps"
      ]
    },
    {
      "id": "title_interpretation",
      "heading": "论文标题解读",
      "required_items": [
        "title_keyword_breakdown",
        "title_phrase_rationale",
        "title_to_method_mapping",
        "title_to_claim_mapping"
      ]
    },
    {
      "id": "true_problem",
      "heading": "这篇论文真正解决的是什么",
      "required_items": [
        "concrete_problem",
        "broader_scientific_problem",
        "why_not_only_a_narrow_engineering_problem"
      ]
    },
    {
      "id": "mentioned_papers_and_open_gaps",
      "heading": "论文中提到的其他论文做了什么、留下了什么空白、与本文是什么关系",
      "required_items": [
        "frequently_mentioned_papers",
        "what_each_prior_paper_solved",
        "remaining_gaps_or_blanks",
        "relation_to_current_paper"
      ]
    },
    {
      "id": "core_method",
      "heading": "核心方法到底在干什么",
      "required_items": [
        "core_judgment_or_intuition",
        "knowledge_dependency_order_symbols_data_model_training_inference_experiments",
        "method_structure_breakdown",
        "key_modules",
        "module_inputs_outputs_symbols_dimensions",
        "trainable_parameters_hyperparameters_and_dataflow",
        "training_pipeline",
        "inference_or_deployment_path",
        "optimization_objectives",
        "communication_or_system_path_when_relevant",
        "pdf_or_latex_key_figure_explanations",
        "figure_to_claim_mapping",
        "module_choices_that_seem_author_specific"
      ]
    },
    {
      "id": "formula_preservation_and_equation_walkthrough",
      "heading": "公式保留与逐式解释",
      "required_items": [
        "preserved_key_equations",
        "term_by_term_equation_explanation",
        "key_concepts_explained_as_intuition_formula_example_limitation",
        "equation_role_in_method",
        "equation_to_algorithm_location",
        "equation_or_theory_choices_that_seem_author_specific"
      ]
    },
    {
      "id": "equation_module_assumption_critique",
      "heading": "具体公式、模块与设计假设的不足及可改进空间",
      "required_items": [
        "formula_level_weaknesses",
        "module_level_weaknesses",
        "assumption_fragility_or_mismatch",
        "optimization_or_efficiency_concerns",
        "possible_alternatives_or_reformulations",
        "improvement_room_and_tradeoffs"
      ]
    },
    {
      "id": "innovation_claim_audit",
      "heading": "创新点、核心主张与证据逐条核对",
      "required_items": [
        "claimed_innovations",
        "core_claims",
        "evidence_type_per_claim",
        "support_strength_per_claim",
        "unsupported_or_weak_claims"
      ]
    },
    {
      "id": "scientific_importance",
      "heading": "这篇论文为什么重要 / 为什么值得被接收",
      "required_items": [
        "scientific_significance",
        "what_assumption_it_challenges_or_preserves",
        "why_reviewers_or_pc_should_care"
      ]
    },
    {
      "id": "experiment_design",
      "heading": "实验是如何被设计出来的",
      "required_items": [
        "experiment_goals_or_validation_chains",
        "dataset_scale_split_protocol_and_label_definition",
        "main_experiments",
        "bridge_experiments",
        "ablation_logic",
        "baseline_source_and_rerun_or_reconstruction_status",
        "metric_meanings_and_interpretation_limits",
        "evidence_to_claim_gap",
        "result_exceptions_and_reproducibility_risks",
        "missing_hardware_runtime_hyperparameter_or_protocol_details",
        "figure_table_data_explanations",
        "visual_or_numeric_evidence_to_claim_mapping",
        "mismatch_or_partial_support_analysis",
        "paper_specific_findings_instead_of_generic_summary"
      ]
    },
    {
      "id": "idea_genesis",
      "heading": "倒推作者怎么想到这个 idea",
      "required_items": [
        "borrowed_algorithm_lineage",
        "idea_genesis_trace",
        "why_the_idea_became_natural",
        "related_papers_worth_linking",
        "subjective_judgment_or_research_style_trace"
      ]
    },
    {
      "id": "research_equation_and_replacement_mechanism",
      "heading": "研究方程与缺失机制替代",
      "required_items": [
        "important_setting",
        "broken_assumption",
        "borrowed_tool",
        "new_constraint",
        "unavailable_ideal_mechanism_Y",
        "constructed_surrogate_mechanism_Z",
        "why_Z_approximates_or_replaces_Y",
        "research_equation_A_notC_T_M_to_Z"
      ]
    },
    {
      "id": "author_direction_discovery_reconstruction",
      "heading": "作者可能如何发现这个方向",
      "required_items": [
        "valuable_field",
        "painful_assumption",
        "emerging_or_borrowed_tool",
        "unserved_setting",
        "blocking_constraint",
        "conceptual_replacement",
        "evidence_backed_vs_speculative_parts"
      ]
    },
    {
      "id": "story_construction_challenge_to_module",
      "heading": "论文故事线如何搭建",
      "required_items": [
        "narrative_escalation",
        "challenge_failure_design_module_evidence_table",
        "additive_vs_closed_loop_story_judgment",
        "flowing_object_through_modules",
        "story_fragile_links"
      ]
    },
    {
      "id": "module_author_thinking_deepread",
      "heading": "模块级作者思路深读",
      "required_items": [
        "failure_fixed_by_each_module",
        "ideal_unavailable_solution",
        "available_proxy",
        "design_choice_and_author_subjectivity",
        "hidden_assumption_H_i",
        "risk_when_not_H_i",
        "future_research_point_from_each_module"
      ]
    },
    {
      "id": "reverse_citation_logic",
      "heading": "关键引用的叙事功能与 Citation-to-Module Map",
      "required_items": [
        "citation_clusters",
        "narrative_function_per_cluster",
        "assumption_inherited",
        "how_current_paper_modifies_prior_work",
        "citation_to_module_map"
      ]
    },
    {
      "id": "experiments_as_story_evidence",
      "heading": "实验作为故事证据",
      "required_items": [
        "experiment_claim_counterfactual_metric_stress_matrix",
        "alternative_explanations_ruled_out",
        "module_justification_by_experiment",
        "stress_condition_validity",
        "ablation_story_alignment"
      ]
    },
    {
      "id": "reusable_story_making_pattern",
      "heading": "可复用的论文造故事模式",
      "required_items": [
        "old_success_new_reality_pattern",
        "replacement_story_pattern",
        "two_axis_empty_cell_pattern",
        "closed_loop_contribution_pattern",
        "how_to_reuse_for_future_papers"
      ]
    },
    {
      "id": "hidden_assumption_to_new_idea",
      "heading": "从隐藏假设生成新 idea",
      "required_items": [
        "hidden_assumption_table",
        "violated_assumption_setting",
        "required_new_mechanism",
        "engineering_vs_boundary_pushing_label",
        "ranked_new_research_questions"
      ]
    },
    {
      "id": "author_subjectivity_linkage",
      "heading": "作者主观判断与研究风格关联分析",
      "required_items": [
        "where_choices_look_author_specific",
        "objective_necessity_vs_author_choice",
        "evidence_backed_subjective_inference",
        "author_style_or_research_taste_signals"
      ]
    },
    {
      "id": "paper_grounded_specificity",
      "heading": "报告具体性要求：必须紧扣论文中的公式、模块、图表、实验与措辞",
      "required_items": [
        "concrete_formula_module_dataset_baseline_mentions",
        "evidence_level_labels_paper_explicit_reasonable_inference_nearby_work_inference_missing",
        "figure_table_and_experiment_specifics",
        "theorem_object_and_assumption_specificity",
        "avoid_generic_high_level_only_summary"
      ]
    },
    {
      "id": "reviewer_focus",
      "heading": "审稿人最关注什么",
      "required_items": [
        "at_least_three_key_concerns",
        "primary_concern_categories",
        "concerns_with_highest_acceptance_impact"
      ]
    },
    {
      "id": "reviewer_lens_enrichment",
      "heading": "额外审稿视角审计（借鉴 GitHub 热门审稿 skill 的 reviewer 关注点）",
      "required_items": [
        "novelty_and_significance_audit",
        "technical_soundness_and_methodology_rigor",
        "reproducibility_and_missing_details",
        "results_claims_alignment",
        "missing_baselines_or_controls",
        "figure_table_clarity_and_honesty_of_limitations",
        "venue_fit_or_acceptance_logic_when_relevant"
      ]
    },
    {
      "id": "author_reply",
      "heading": "作者是怎么回复的",
      "required_items": [
        "direct_replies_to_major_concerns"
      ]
    },
    {
      "id": "reviewer_acceptance",
      "heading": "审稿人是否认同作者回复",
      "required_items": [
        "meta_review_or_decision_signal",
        "resolved_points",
        "remaining_unresolved_points"
      ]
    },
    {
      "id": "review_coverage_check",
      "heading": "审稿意见回复覆盖核对",
      "required_items": [
        "concern_reply_resolution_mapping",
        "coverage_conclusion"
      ]
    },
    {
      "id": "strengths",
      "heading": "这篇论文最强的地方",
      "required_items": [
        "at_least_three_strengths"
      ]
    },
    {
      "id": "weaknesses",
      "heading": "这篇论文的弱点 / 不足",
      "required_items": [
        "at_least_three_weaknesses",
        "open_risks",
        "unresolved_questions",
        "failure_modes_or_scope_limits",
        "structural_limitations"
      ]
    },
    {
      "id": "team_continuation",
      "heading": "作者团队近年的相关延续",
      "required_items": [
        "follow_up_papers_or_repos",
        "lab_or_team_agenda_signal",
        "title_based_author_lookup_sources",
        "confirmed_author_identity",
        "team_related_papers_ranked",
        "continuation_vs_gap_assessment"
      ]
    },
    {
      "id": "future_boundaries",
      "heading": "从这篇论文出发，最值得突破的未来边界",
      "required_items": [
        "at_least_three_future_directions",
        "which_directions_are_only_engineering_extensions",
        "which_directions_may_push_scientific_boundaries"
      ]
    },
    {
      "id": "innovation_type_and_boundary_judgment",
      "heading": "创新类型判断：这是增量创新、交叉创新，还是边界突破",
      "required_items": [
        "innovation_type_judgment",
        "why_incremental_or_cross",
        "disciplinary_boundary_crossing",
        "boundary_breaking_limits"
      ]
    },
    {
      "id": "topic_takeaways",
      "heading": "对选题的直接启示",
      "required_items": [
        "borrowable_mechanisms",
        "next_experiments",
        "what_should_enter_graph_stage"
      ]
    },
    {
      "id": "new_directions_and_fresh_hooks",
      "heading": "可能的新研究方向或新创新点（尤其是可能推动科学边界的方向）",
      "required_items": [
        "native_extensions",
        "cross_domain_transfers",
        "migrated_or_hybrid_hooks",
        "high_risk_high_reward_ideas",
        "boundary_pushing_direction_candidates"
      ]
    },
    {
      "id": "plain_language_summary",
      "heading": "最后一段通俗故事总结",
      "required_items": [
        "plain_language_analogy_or_story"
      ]
    },
    {
      "id": "reference_sources",
      "heading": "参考来源",
      "required_items": [
        "primary_sources",
        "supporting_sources"
      ]
    },
    {
      "id": "appendix_problem_provenance",
      "heading": "上位科学问题定位的三条证据链",
      "required_items": [
        "paper_explicit_path",
        "borrowed_algorithm_path",
        "new_algorithm_bottleneck_path"
      ]
    },
    {
      "id": "appendix_unified_ml_problems",
      "heading": "统一后的更高层 AI/ML 问题",
      "required_items": [
        "ml_problem_set_with_provenance"
      ]
    },
    {
      "id": "appendix_borrowed_upper_problems",
      "heading": "借鉴算法所属上位问题",
      "required_items": [
        "borrowed_upper_problem_list"
      ]
    },
    {
      "id": "appendix_bottleneck_upper_problems",
      "heading": "新算法遇到的问题所对应的上位问题",
      "required_items": [
        "bottleneck_upper_problem_list"
      ]
    },
    {
      "id": "appendix_module_mapping",
      "heading": "模块到问题、算法与瓶颈的映射",
      "required_items": [
        "module_to_problem_mapping",
        "module_to_algorithm_lineage",
        "module_to_bottleneck_mapping"
      ]
    },
    {
      "id": "appendix_graph_candidates",
      "heading": "知识图谱节点与关系候选",
      "required_items": [
        "graph_node_candidates",
        "graph_relation_candidates"
      ]
    },
    {
      "id": "appendix_pipeline_summary",
      "heading": "提出算法的模型、架构、训练与推理流程",
      "required_items": [
        "model_form",
        "architecture_summary",
        "key_modules",
        "training_pipeline",
        "inference_pipeline",
        "optimization_objectives",
        "module_inputs_outputs_symbols_dimensions_training_parameters_and_dataflow",
        "communication_or_deployment_path"
      ]
    },
    {
      "id": "appendix_algorithm_example",
      "heading": "带具体例子的算法步骤演示",
      "required_items": [
        "worked_example_setup",
        "step_by_step_state_updates",
        "example_inputs_outputs",
        "complete_numeric_training_to_inference_walkthrough",
        "learned_parameters_vs_fixed_hyperparameters",
        "example_revealed_failure_or_advantage"
      ]
    },
    {
      "id": "appendix_related_papers",
      "heading": "相关论文与关联理由",
      "required_items": [
        "related_papers_and_rationales"
      ]
    },
    {
      "id": "appendix_mentioned_paper_gap_map",
      "heading": "论文中反复提到的关键文献及其未解空白",
      "required_items": [
        "key_repeatedly_discussed_papers",
        "unsolved_gaps_carried_forward",
        "why_current_paper_targets_those_gaps"
      ]
    },
    {
      "id": "appendix_review_coverage",
      "heading": "审稿覆盖核对",
      "required_items": [
        "review_reply_chain_check",
        "report_level_coverage_conclusion"
      ]
    },
    {
      "id": "appendix_visual_findings",
      "heading": "架构图 / 模型图 / 结果图补充",
      "required_items": [
        "important_figures_or_pages",
        "what_each_visual_clarifies",
        "figure_to_claim_mapping",
        "latex_figure_caption_label_context_when_available",
        "what_each_visual_still_leaves_unclear"
      ]
    },
    {
      "id": "appendix_figure_blueprints",
      "heading": "架构图 / 模型图设计方案",
      "required_items": [
        "reusable_figure_blueprints",
        "visual_prompt_blueprints",
        "multi_image_camera_style_logic_continuity_prompt_blueprints",
        "split_into_multiple_images_not_one_compressed_image",
        "source_grounding_and_hallucination_check"
      ]
    },
    {
      "id": "appendix_experiment_borrowing",
      "heading": "实验图表设计可借鉴点",
      "required_items": [
        "reusable_experiment_or_table_patterns"
      ]
    },
    {
      "id": "appendix_baseline_genealogy",
      "heading": "实验设置与比较算法谱系对应表",
      "required_items": [
        "datasets_metrics_protocols",
        "dataset_scale_label_definition_split_protocol",
        "baseline_to_related_work_mapping",
        "baseline_source_and_whether_rerun_reconstructed_or_imported",
        "why_each_baseline_was_included",
        "intro_relatedwork_to_experiment_link"
      ]
    },
    {
      "id": "appendix_experiment_purpose_and_findings",
      "heading": "各实验环节的目的、支撑主张与现象总结",
      "required_items": [
        "experiment_block_purpose",
        "claim_supported_by_each_block",
        "table_chart_data_explanation",
        "metric_meanings_result_exceptions_and_reproduction_risks",
        "support_vs_contradiction_vs_partial_support",
        "surprising_or_controversial_findings",
        "limitations_exposed_by_experiments",
        "possible_causes_of_mismatch"
      ]
    },
    {
      "id": "appendix_innovation_hooks",
      "heading": "可继续追的创新点",
      "required_items": [
        "innovation_hooks"
      ]
    },
    {
      "id": "scientific_gap_and_positioning",
      "heading": "Scientific Problem, Missing Gap, And Literature Positioning",
      "required_items": [
        "paper_level_scientific_problem",
        "claimed_missing_gap",
        "closest_literature_threads",
        "borrowed_method_families",
        "what_is_improved_over_prior_work"
      ]
    },
    {
      "id": "claim_support_matrix",
      "heading": "Claim-Support Matrix",
      "required_items": [
        "claim_rows",
        "evidence_columns",
        "support_strength_scale",
        "missing_support_notes"
      ]
    },
    {
      "id": "symbols_and_concepts",
      "heading": "Symbols, Definitions, And Core Concepts For Beginners",
      "required_items": [
        "main_symbols",
        "core_definitions",
        "task_setting_for_beginners"
      ]
    },
    {
      "id": "core_algorithm_procedure",
      "heading": "Core Algorithm And Procedure",
      "required_items": [
        "step_by_step_algorithm",
        "inputs_outputs_and_states",
        "novel_vs_inherited_parts"
      ]
    },
    {
      "id": "algorithm_example_for_beginners",
      "heading": "Algorithm Walkthrough With A Concrete Example",
      "required_items": [
        "mini_case_setup",
        "step_by_step_walkthrough",
        "where_novelty_enters",
        "what_the_example_teaches"
      ]
    },
    {
      "id": "theory_and_proofs",
      "heading": "Theory, Proofs, And Their Role",
      "required_items": [
        "theorems_or_lemmas",
        "why_proofs_are_needed",
        "proof_assumptions",
        "practical_algorithm_relevance",
        "theory_to_algorithm_gap"
      ]
    },
    {
      "id": "theory_proof_implementation_mapping",
      "heading": "理论、证明与实现步骤对照",
      "required_items": [
        "theorem_to_algorithm_step_mapping",
        "assumption_to_implementation_mapping",
        "exact_match_vs_local_approximation",
        "practical_significance_of_theory",
        "where_theory_stops_matching_practice"
      ]
    },
    {
      "id": "experiment_logic",
      "heading": "Experimental Design Logic And Author Reasoning",
      "required_items": [
        "dataset_baseline_metric_choice_rationale",
        "dataset_scale_labels_baseline_rerun_status_metric_meaning",
        "major_experiment_doubts_preempted",
        "missing_experiment_details_hardware_runtime_hyperparameters_data_split",
        "reasoning_chain_from_idea_to_experiment_plan"
      ]
    },
    {
      "id": "probe_models_and_mechanism_checks",
      "heading": "Probe Models, Bridge Experiments, And Mechanism Checks",
      "required_items": [
        "exploratory_models_or_probes",
        "bridge_experiments",
        "mechanism_checks_strength"
      ]
    },
    {
      "id": "interesting_phenomena",
      "heading": "Interesting Empirical Phenomena And Lessons",
      "required_items": [
        "surprising_results",
        "scientific_lessons",
        "follow_up_tests_implied"
      ]
    },
    {
      "id": "innovation_type_and_boundary_appendix",
      "heading": "Innovation Type And Boundary-Crossing Judgment",
      "required_items": [
        "incremental_vs_cross_type",
        "why_it_counts_or_not",
        "discipline_boundary_assessment",
        "future_crossings_suggested"
      ]
    },
    {
      "id": "author_team_continuation_from_upstream_materials",
      "heading": "Author-Team Continuation Notes From Upstream Materials",
      "required_items": [
        "upstream_author_context_used",
        "confirmed_authors_from_upstream_or_paper",
        "team_continuation_if_already_available",
        "missing_context_not_collected_here"
      ]
    },
    {
      "id": "external_retrieval_deferred",
      "heading": "External Retrieval Deferred To Collection Stage",
      "required_items": [
        "no_new_external_retrieval_rule",
        "missing_external_context_for_later_collection_stage",
        "stage_boundary_note"
      ]
    },
    {
      "id": "routing_appendix",
      "heading": "Routing Appendix",
      "required_items": [
        "current_status",
        "produced_artifacts",
        "possible_user_inputs_for_next_stage"
      ]
    },
    {
      "id": "teaching_audience_and_goal",
      "heading": "面向讲解的受众画像与讲解目标",
      "required_items": [
        "target_audience",
        "prior_knowledge",
        "likely_confusions",
        "teaching_goal",
        "math_depth",
        "evidence_needed"
      ]
    },
    {
      "id": "three_layer_teaching_summary",
      "heading": "3 层讲解摘要：30 秒 / 3 分钟 / 10 分钟",
      "required_items": [
        "thirty_second_version",
        "three_minute_version",
        "ten_minute_version",
        "core_caveat_preserved"
      ]
    },
    {
      "id": "teaching_story_spine",
      "heading": "讲解主线 Story Spine",
      "required_items": [
        "before",
        "pain",
        "broken_assumption",
        "key_replacement",
        "mechanism",
        "evidence",
        "caveat",
        "next_idea"
      ]
    },
    {
      "id": "audience_prerequisites",
      "heading": "听众先修知识与概念铺垫",
      "required_items": [
        "task_setting",
        "symbols",
        "field_conventions",
        "datasets_or_benchmarks",
        "assumptions",
        "minimum_background"
      ]
    },
    {
      "id": "formula_visual_experiment_teaching_script",
      "heading": "公式 / 图表 / 实验的讲解脚本",
      "required_items": [
        "formula_teaching_table",
        "visual_teaching_table",
        "experiment_teaching_units",
        "what_not_to_overclaim"
      ]
    },
    {
      "id": "blackboard_derivation_and_toy_example",
      "heading": "板书推导与小例子演示",
      "required_items": [
        "mini_case_setup",
        "step_by_step_derivation",
        "state_updates",
        "teaching_takeaway",
        "where_simplification_breaks"
      ]
    },
    {
      "id": "role_play_discussion_questions",
      "heading": "角色扮演式讨论问题",
      "required_items": [
        "archaeologist",
        "bug_hunter",
        "researcher",
        "industry_practitioner",
        "social_impact_assessor",
        "author_defender",
        "teacher"
      ]
    },
    {
      "id": "likely_questions_and_evidence_backed_answers",
      "heading": "可能被问到的问题与回答证据",
      "required_items": [
        "beginner_questions",
        "peer_questions",
        "advisor_reviewer_questions",
        "practitioner_questions",
        "evidence_links",
        "confidence_or_uncertainty"
      ]
    },
    {
      "id": "misunderstanding_guardrails",
      "heading": "易误解点与纠偏",
      "required_items": [
        "paper_does_not_claim",
        "analogy_limits",
        "overgeneralization_risks",
        "baseline_overinterpretation",
        "limitation_to_state_aloud"
      ]
    },
    {
      "id": "ppt_or_talk_blueprint",
      "heading": "PPT / 分享稿结构草案",
      "required_items": [
        "slide_blueprint",
        "speaker_notes",
        "transitions",
        "likely_questions",
        "time_budget"
      ]
    },
    {
      "id": "three_takeaways_for_audience",
      "heading": "听众可带走的三句话",
      "required_items": [
        "takeaway_1",
        "takeaway_2",
        "takeaway_3"
      ]
    }
  ],
  "mandatory_section_headings": [
    "论文信息",
    "论文标题解读",
    "这篇论文真正解决的是什么",
    "论文中提到的其他论文做了什么、留下了什么空白、与本文是什么关系",
    "核心方法到底在干什么",
    "公式保留与逐式解释",
    "具体公式、模块与设计假设的不足及可改进空间",
    "创新点、核心主张与证据逐条核对",
    "这篇论文为什么重要 / 为什么值得被接收",
    "实验是如何被设计出来的",
    "倒推作者怎么想到这个 idea",
    "研究方程与缺失机制替代",
    "作者可能如何发现这个方向",
    "论文故事线如何搭建",
    "模块级作者思路深读",
    "关键引用的叙事功能与 Citation-to-Module Map",
    "实验作为故事证据",
    "可复用的论文造故事模式",
    "从隐藏假设生成新 idea",
    "审稿人最关注什么",
    "额外审稿视角审计（借鉴 GitHub 热门审稿 skill 的 reviewer 关注点）",
    "作者是怎么回复的",
    "审稿人是否认同作者回复",
    "审稿意见回复覆盖核对",
    "这篇论文最强的地方",
    "这篇论文的弱点 / 不足",
    "作者团队近年的相关延续",
    "从这篇论文出发，最值得突破的未来边界",
    "创新类型判断：这是增量创新、交叉创新，还是边界突破",
    "对选题的直接启示",
    "可能的新研究方向或新创新点（尤其是可能推动科学边界的方向）",
    "面向讲解的受众画像与讲解目标",
    "3 层讲解摘要：30 秒 / 3 分钟 / 10 分钟",
    "讲解主线 Story Spine",
    "听众先修知识与概念铺垫",
    "公式 / 图表 / 实验的讲解脚本",
    "板书推导与小例子演示",
    "角色扮演式讨论问题",
    "可能被问到的问题与回答证据",
    "易误解点与纠偏",
    "PPT / 分享稿结构草案",
    "听众可带走的三句话",
    "最后一段通俗故事总结",
    "参考来源",
    "上位科学问题定位的三条证据链",
    "统一后的更高层 AI/ML 问题",
    "借鉴算法所属上位问题",
    "新算法遇到的问题所对应的上位问题",
    "模块到问题、算法与瓶颈的映射",
    "知识图谱节点与关系候选",
    "提出算法的模型、架构、训练与推理流程",
    "带具体例子的算法步骤演示",
    "相关论文与关联理由",
    "论文中反复提到的关键文献及其未解空白",
    "审稿覆盖核对",
    "架构图 / 模型图 / 结果图补充",
    "架构图 / 模型图设计方案",
    "实验图表设计可借鉴点",
    "实验设置与比较算法谱系对应表",
    "各实验环节的目的、支撑主张与现象总结",
    "可继续追的创新点",
    "Scientific Problem, Missing Gap, And Literature Positioning",
    "Claim-Support Matrix",
    "Symbols, Definitions, And Core Concepts For Beginners",
    "Core Algorithm And Procedure",
    "Algorithm Walkthrough With A Concrete Example",
    "Theory, Proofs, And Their Role",
    "理论、证明与实现步骤对照",
    "Experimental Design Logic And Author Reasoning",
    "Probe Models, Bridge Experiments, And Mechanism Checks",
    "Interesting Empirical Phenomena And Lessons",
    "Innovation Type And Boundary-Crossing Judgment",
    "Author-Team Continuation Notes From Upstream Materials",
    "External Retrieval Deferred To Collection Stage",
    "Routing Appendix",
    "idea / 理论证明 / 具体算法或模块里哪些部分更像作者的主观选择、经验判断或研究风格",
    "报告必须结合论文本身的具体模块、公式、图表、实验、数据与原文表述，避免空泛抽象总结"
  ]
}


path: schemas/extended_deepread_checklist_cn.md
content: # 扩展精读检查清单（增强版）

在原始 deep-read 基础上，生成每篇论文报告前，至少逐项核对：

1. 是否单独解释了标题中的关键词，以及标题与正文的映射。
2. 是否说明了论文真正解决的问题，以及连续的上位问题阶梯。
3. 是否把论文中反复提到的关键文献拆开讲，并指出它们遗留的空白。
4. 是否逐条核对了创新点和主张，并标出证据类型与强度。
5. 是否倒推了作者的研究思路来源，并区分证据与推测。
6. 是否解释了符号、定义、设定和核心概念。
7. 是否完整保留了关键公式，并逐式解释每个公式项、作用与上下文。
8. 如果有证明，是否把定理 / 引理 / 假设 / 结论与实际算法步骤或实现流程对应起来，并说明二者是严格一致、局部近似，还是仅提供动机。
9. 是否不仅解释了公式和模块“在做什么”，还判断了关键公式、关键模块、关键假设是否存在脆弱点、欠论证之处、优化困难、计算代价问题或可替代设计空间。
10. 是否给出了针对这些公式 / 模块 / 假设的具体改进空间、替代方案与潜在 trade-off。
11. 是否给出了带具体例子的算法流程，而不是只写公式。
12. 是否把实验中的 baseline 与引言 / 相关工作中的方法谱系对应起来。
13. 是否说明了每个实验块要回答什么问题、支撑什么主张。
14. 是否指出了有趣、反常或有争议的实验现象。
15. 是否借鉴热门 GitHub 审稿 skill 的 reviewer 关注点，额外检查了 novelty、significance、soundness、methodology rigor、reproducibility、results-claims alignment、missing baselines/controls、figure/table clarity、limitations honesty 等维度。
16. 如果有 LaTeX 源，是否基于 figure 环境、caption、label、引用正文和图片路径解释了关键图，而不是因为不是 PDF 就跳过图。
17. 如果有 PDF 源，是否也显式解释了关键图（结构图、流程图、定性图、实验曲线图等），而不是只关注文字和公式。
18. 是否对实验中的关键图表、曲线、表格和数据做了解释，并明确它们各自支撑哪个主张。
19. 是否指出了实验图表 / 数据与作者主张之间不一致、部分一致或解释不足的地方，并分析了可能原因。
20. 是否判断了创新是增量、交叉、边界突破，还是混合型。
21. 是否讨论了是否突破学科边界，以及边界突破的限度。
22. 是否明确讨论了论文的不足、未解决问题、失败模式、适用范围边界，以及哪些局限是结构性的。
23. 是否区分了普通后续工作与真正可能推动科学边界的研究方向。
24. 是否提出了新的研究方向，包括原生延展、交叉迁移、混合创新，以及高风险高回报的边界型方向。
25. 是否用一个通俗、生动的故事收尾。
26. 是否优先保证完整性，而不是人为压缩篇幅。

27. 在介绍 idea、理论证明、具体算法或模块时，是否识别并说明了哪些部分可能体现作者的主观判断、经验偏好、启发式选择、研究风格或工程取舍，并区分客观必要性与作者选择。
28. 全文是否结合论文本身的具体公式、模块名、假设、数据集、baseline、图表、定理对象、实验现象和措辞展开，而不是停留在空泛抽象层面。

29. 是否抽取了论文的 research equation：重要设定 + 被打破假设 + 借用工具 + 新约束 + 替代机制。
30. 是否明确指出了 easier setting 中可用但 target setting 中不可用的理想机制 `Y`，以及论文构造的替代机制 `Z`。
31. 是否重建了作者可能如何发现该方向：valuable field、painful assumption、emerging / borrowed tool、unserved setting、blocking constraint、conceptual replacement。
32. 是否建立了 challenge -> failure mode -> design principle -> module -> evidence 的故事桥接表。
33. 是否判断方法是模块堆叠还是闭环贡献，并指出在模块间流动的核心对象。
34. 是否对每个核心模块使用 Failure + Unavailable Ideal + Available Proxy + Design Choice + Assumption + Risk 模板进行作者思路深读。
35. 是否把关键引用解释为叙事功能，而不是只做背景文献罗列，并形成 Citation-to-Module Map。
36. 是否把每个实验解释为 claim + counterfactual + metric + stress condition，并判断实验是否真的支撑故事链条。
37. 是否抽取出可复用的论文造故事模式，如 replacement story、two-axis empty cell、closed-loop contribution。
38. 是否把隐藏假设 `H_i` 系统转化为 `¬H_i` 下的新研究问题，并区分普通工程延展与可能推动科学边界的方向。
39. 是否避免泛泛总结，把关键方法解释到读者能够复现、答辩、讲给别人听。
40. 是否所有关键概念都按“直觉 -> 数学公式或 formal definition -> 具体例子 -> 局限 / failure case”展开。
41. 是否复杂模块都说明了输入、输出、符号、维度、训练参数、固定超参数、训练数据流和推理数据流。
42. 是否严格区分“论文明确写明”“论文没写但合理推测”“参考相近工作推测”“缺失 / 未报告”。
43. 是否显式列出缺失的硬件、耗时、内存、优化器、学习率、随机种子、早停、超参搜索、baseline 来源、baseline 是否重跑或重构、数据划分、标签定义、代码和计算预算。
44. 是否实验部分足够细：数据集规模、标签定义、划分协议、baseline 谱系、指标含义、主结果例外、消融目的、定性证据和复现风险都已说明。
45. 是否最后提供了一个完整数字例子，把训练和推理串起来，并标注哪些部分是论文明确给出的，哪些只是教学用 toy simplification。
46. 是否整体讲解顺序体现知识依赖：先符号和设定，再数据和输入，再模型模块，再训练与推理，最后实验、不足和复现风险。
47. 若生成生图提示，是否要求“多张连续的卡通图”，并明确拆成多张 separate 16:9 images/cards，而不是压缩到一张图里。
48. 若生成连续漫画提示，是否包含运镜计划、风格 bible、角色/色彩/字体/编号一致性、与前序图片的连续性，以及源文和精读报告的事实核对。
49. 若是后续部分生图，是否明确复用前面已生成图片的视觉设定和叙事状态；若前图不在上下文，是否只复用非事实视觉风格而不编造论文内容。
50. 是否在提示用户下一步怎么说时，显式提醒用户使用“生成多张连续的卡通图”这句话。


path: schemas/external_best_practices_sources.md
content: # External Best-Practice Sources Used For The Teaching-Explainer Overlay

These sources informed the teaching overlay through v1.2.0. They are not a substitute for paper-grounded evidence in a concrete report.

## Paper reading and reconstruction

- S. Keshav, "How to Read a Paper" / ACM SIGCOMM CCR: three-pass reading method; use for orientation, content, and deep reconstruction.
  - URL: https://ccr.sigcomm.org/online/files/p83-keshavA.pdf

## Role-based discussion and seminar teaching

- Alec Jacobson and Colin Raffel, "Role-Playing Paper-Reading Seminars": rotate roles such as researcher, practitioner, hacker, social-impact assessor; the goal is deeper critical analysis and discussion rather than one-way summary.
  - URL: https://colinraffel.com/blog/role-playing-seminar.html
- Stanford CS324 paper discussions: panel roles including Archaeologist, Social Impact Assessor, Industry Practitioner, Researcher, Salesperson, and Bug Hunter.
  - URL: https://github.com/stanford-cs324/winter2022/blob/master/paper-discussions.md
- CS496 seminar guidance: paper presentations should cover high-level ideas, key technical details, experimental results, background/related work, shortcomings, and 3-5 discussion questions.
  - URL: https://github.com/andrewcrotty/cs496-f22/blob/main/README.md

## Story and audience framing

- MIT EECS Communication Lab, "Paper: Introduction": problem, motivation, solution, contributions; work backward from what was done to construct the narrative.
  - URL: https://mitcommlab.mit.edu/eecs/commkit/journal-article-introduction/

## Review and evidence criteria

- AISTATS 2026 Reviewer Guidelines: evaluate soundness, significance, novelty, clarity, relation to prior work, and non-conventional contributions; reviews should be specific, fair, useful, and constructive.
  - URL: https://virtual.aistats.org/Conferences/2026/ReviewerGuidelines
- ICLR 2026 Author Guide: reproducibility statement should reference details such as code, assumptions, proofs, data processing, and appendix/supplementary materials.
  - URL: https://iclr.cc/Conferences/2026/AuthorGuide
- Bytedance Deer Flow academic-paper-review skill: includes review axes such as soundness, novelty, reproducibility, experimental design, statistical rigor, scalability, and significance level.
  - URL: https://github.com/bytedance/deer-flow/blob/main/skills/public/academic-paper-review/SKILL.md

## Public skill patterns

- ClawHub paper-reading skill: emphasizes thorough paper reading, Markdown report output, optional architecture diagrams, and epistemic tags such as paper-grounded vs inferred vs external claims.
  - URL: https://clawhub.ai/wooonster/paper-reading
- Datawhale OpenClaw paper assistant tutorial: demonstrates an automated research-assistant workflow from paper fetching to filtering, deep-reading, and push notification. This v1.2.0 skill does not reopen retrieval inside the deep-read stage; it only borrows the idea that paper understanding should close the loop into usable delivery artifacts.
  - URL: https://github.com/datawhalechina/hello-claw/blob/main/docs/cn/university/paper-assistant/index.md


path: schemas/motivation_bridge_analysis.md
content: # Motivation-Bridge Analysis

Do not only describe the final algorithm. Also identify how the paper tries to make the jump from motivation to method scientifically believable.

Look for:

- small experiments
- probes
- pilot designs
- explanatory ablations
- toy demonstrations
- visualizations that justify the mechanism

For each bridge item, record:

- what claim it is trying to support
- what doubt it tries to preempt
- what was observed
- whether it strongly, weakly, or only suggestively closes the gap between motivation and algorithm

## Research-Generative Bridge Add-on

Also ask how the paper made its main surrogate mechanism feel inevitable:

- What ideal mechanism would have solved the problem in an easier setting?
- Why is that ideal mechanism unavailable here?
- What proxy signal remains available?
- How does the proposed module transform that proxy into a surrogate mechanism?
- Which hidden assumption must hold for the surrogate to work?
- If that hidden assumption fails, what new research question appears?

Record this as:

| Module | Failure fixed | Ideal unavailable mechanism | Available proxy | Surrogate design | Hidden assumption | New idea under violated assumption |
|---|---|---|---|---|---|---|


path: schemas/paper_focus_spec.template.json
content: {
  "paper_id": "string",
  "title": "string",
  "venue": "string",
  "year": 2026,
  "openreview_forum_url": "",
  "source_record": {
    "status": "",
    "status_bucket": "accepted | not_accepted | status_unknown",
    "verification_state": "unverified | partially_verified | fully_verified",
    "verification_checks": {
      "title_verified": false,
      "authors_verified": false,
      "year_verified": false,
      "venue_verified": false,
      "status_verified": false
    },
    "match_reason": "",
    "canonical_paper_page_url": "",
    "source_url": "",
    "conference_paper_url": "",
    "conference_pdf_url": "",
    "openreview_forum_url": "",
    "openreview_pdf_url": "",
    "arxiv_abs_url": "",
    "arxiv_pdf_url": "",
    "arxiv_latex_url": "",
    "preferred_source_type": "",
    "preferred_local_source_path": "",
    "local_latex_dir": "",
    "local_pdf_path": "",
    "local_openreview_pdf_path": "",
    "local_official_pdf_path": "",
    "local_arxiv_pdf_path": "",
    "review_bundle_dir": "",
    "review_digest_path": "",
    "canonical_review_source_type": "",
    "missing_source_after_exhaustive_search": false,
    "source_acquisition_status": "materialized | partial | missing_source",
    "source_stage": "",
    "artifact_status": "",
    "why_collected": "",
    "notes": [],
    "retrieval_sources": [],
    "review_bundle_completeness": {
      "forum": false,
      "reviews_or_meta_reviews": false,
      "author_responses": false,
      "decision": false
    }
  },
  "upstream_bundle_context": {
    "routing_status_json": "",
    "project_directory_index_json": "",
    "project_directory_index_md": "",
    "paper_batch_manifest_json": "",
    "openreview_rebuttal_digest_json": "",
    "stage_delivery_handoff_md": "",
    "delivery_bundle_manifest_json": ""
  },
  "problem_source_paths": [
    "paper-explicit",
    "borrowed-algorithm-ancestry",
    "new-algorithm-bottleneck"
  ],
  "explicit_higher_ml_ai_problems": [],
  "higher_ml_ai_problems": [],
  "higher_problem_map": {
    "paper_explicit": [],
    "algorithm_ancestry": [],
    "algorithm_bottleneck": []
  },
  "algorithm_ancestry_upper_problems": [
    {
      "problem": "string",
      "why": "string",
      "trigger_algorithms": [],
      "source_modules": []
    }
  ],
  "algorithm_encountered_problem_upper_problems": [
    {
      "problem": "string",
      "why": "string",
      "trigger_issue": "string",
      "source_modules": []
    }
  ],
  "field_problems": [],
  "direction_native_problems": [],
  "module_to_problem_map": [
    {
      "module": "string",
      "module_role": "string",
      "instantiated_ml_ai_problems": [],
      "instantiated_field_problems": [],
      "likely_algorithm_lineage": [],
      "borrowed_algorithm_upper_problems": [
        {
          "problem": "string",
          "why": "string",
          "trigger_algorithms": []
        }
      ],
      "encountered_issue": "string",
      "encountered_problem_upper_problems": [
        {
          "problem": "string",
          "why": "string",
          "trigger_issue": "string"
        }
      ]
    }
  ],
  "graph_node_candidates": [],
  "graph_relation_candidates": [],
  "related_papers": [],
  "idea_genesis": {
    "summary": "",
    "trace": []
  },
  "motivation_bridge": {
    "motivation_claims": [],
    "bridge_experiments": [
      {
        "name": "string",
        "kind": "probe | ablation | pilot-design | sanity-check | mechanism-check | toy-experiment | visualization",
        "what_it_tests": "string",
        "why_it_exists": "string",
        "observed_takeaway": "string",
        "how_it_closes_gap": "string",
        "bridge_strength": "strong | medium | weak"
      }
    ],
    "trial_designs_before_final_method": [],
    "bridge_summary": "",
    "remaining_gap": ""
  },
  "algorithm_design": {
    "model_form": "",
    "architecture_summary": "",
    "key_modules": [],
    "training_pipeline": [],
    "inference_pipeline": [],
    "optimization_objectives": [],
    "communication_or_deployment_path": ""
  },
  "review_context": {
    "required": false,
    "source_type": "none"
  },
  "figure_targets": [],
  "innovation_hooks": [],
  "upstream_author_team_context": {
    "used_existing_context": false,
    "context_sources": [],
    "confirmed_authors_from_upstream_or_paper": [],
    "team_related_papers_if_already_available": [],
    "team_agenda_summary_if_available": "string",
    "missing_context_not_collected_here": []
  },
  "external_followup_deferred": {
    "no_new_external_retrieval_in_this_stage": true,
    "followup_needs_for_collection_stage": [],
    "stage_boundary_note": "Record retrieval gaps for later collection-stage work instead of reopening search inside deep reading."
  },
  "research_generative_reading": {
    "research_equation": {
      "important_setting": "",
      "broken_assumption": "",
      "borrowed_tool": "",
      "new_constraint": "",
      "unavailable_ideal_mechanism_Y": "",
      "constructed_surrogate_mechanism_Z": "",
      "why_Z_approximates_Y": ""
    },
    "author_side_direction_discovery": {
      "valuable_field": "",
      "painful_assumption": "",
      "emerging_or_borrowed_tool": "",
      "unserved_setting": "",
      "blocking_constraint": "",
      "conceptual_replacement": "",
      "evidence_backed_vs_speculative_notes": ""
    },
    "story_construction": {
      "challenge_failure_design_module_evidence": [],
      "additive_vs_closed_loop_judgment": "",
      "flowing_object": "",
      "fragile_links": []
    },
    "module_author_thinking": [],
    "reverse_citation_logic": [],
    "experiments_as_story_evidence": [],
    "reusable_story_making_patterns": [],
    "hidden_assumption_to_new_idea": []
  },
  "teaching_explanation_reading": {
    "audience_profile": {
      "primary_audience": "",
      "secondary_audience": "",
      "beginner_prerequisites": [],
      "likely_confusions": [],
      "math_depth": ""
    },
    "three_layer_summary": {
      "thirty_seconds": "",
      "three_minutes": "",
      "ten_minutes": ""
    },
    "story_spine": {},
    "formula_teaching": [],
    "visual_teaching": [],
    "experiment_teaching": [],
    "role_play_discussion_pack": [],
    "qa_bank": [],
    "misunderstanding_guardrails": [],
    "slide_blueprint": [],
    "teachback_self_test": [],
    "three_takeaways": []
  }
}

path: schemas/per_paper_output_layout.md
content: # Per-Paper Output Layout

Prefer this layout for each paper inside the refreshed bundle:

```text
reports/
  per_paper/
    <paper-slug>/
      <paper-slug>_detailed_cn.md
      <paper-slug>_detailed_cn.pdf
generated/
  intermediate/
    <paper-slug>.json
generated/
  teaching/
    <paper-slug>/
      teaching_outline_cn.md
      slide_blueprint_cn.json
      qa_bank_cn.json
      role_play_discussion_pack_cn.md
generated/
  visuals/
    <paper-slug>/
      pages/
      visual_manifest.json
metadata/
  project_directory_index.json
```

For a session to be restartable from the next stage, the bundle should also carry:

- `metadata/delivery_bundle_manifest.json`
- `metadata/routing_status.json`
- `metadata/project_directory_index.json`
- `reports/project_directory_index.md`
- `reports/stage_delivery_handoff.md`
- `metadata/paper_batch_manifest.json`
- one per-paper `metadata/focus_specs/<paper-slug>.json` carrying the upstream `source_record` snapshot and upstream bundle context
- any review / rebuttal bundle needed by the paper

Teaching sidecars are optional derivatives. They must not replace `reports/per_paper/<paper-slug>/<paper-slug>_detailed_cn.md`, which remains the single authoritative report.


path: schemas/project_directory_annotations.template.json
content: {
  "default_stage": "chatgpt_paper_deep_reading_skill_source",
  "rules": [
    {
      "path": ".",
      "kind": "directory",
      "purpose": "Deep-read workspace root.",
      "generated_by_stage": "chatgpt_paper_deep_reading_skill_source",
      "status": "active"
    },
    {
      "path": "inputs",
      "kind": "directory",
      "purpose": "Uploaded paper sources, review context, and upstream metadata.",
      "generated_by_stage": "chatgpt_paper_deep_reading_skill_source",
      "status": "active"
    },
    {
      "path": "inputs/papers",
      "kind": "directory",
      "purpose": "Authoritative paper sources for the deep-read batch.",
      "generated_by_stage": "chatgpt_paper_deep_reading_skill_source",
      "status": "active"
    },
    {
      "path": "inputs/review_context",
      "kind": "directory",
      "purpose": "Peer-review and rebuttal context used during the deep read.",
      "generated_by_stage": "chatgpt_paper_deep_reading_skill_source",
      "status": "active"
    },
    {
      "path": "reports/per_paper",
      "kind": "directory",
      "purpose": "Per-paper authoritative report folders.",
      "generated_by_stage": "chatgpt_paper_deep_reading_skill_source",
      "status": "active"
    },
    {
      "path": "reports/stage_delivery_handoff.md",
      "kind": "file",
      "purpose": "Authoritative delivery note describing batch completeness, directory meanings, valid versus unresolved artifacts, and the next-stage handoff contract.",
      "generated_by_stage": "chatgpt_paper_deep_reading_skill_source",
      "status": "active"
    },
    {
      "path": "metadata/delivery_bundle_manifest.json",
      "kind": "file",
      "purpose": "Machine-readable restart contract describing which artifacts a fresh downstream session should read first.",
      "generated_by_stage": "chatgpt_paper_deep_reading_skill_source",
      "status": "active"
    },
    {
      "path": "metadata/focus_specs",
      "kind": "directory",
      "purpose": "Per-paper focus specs used as graph-ready scratchpads before the final report.",
      "generated_by_stage": "chatgpt_paper_deep_reading_skill_source",
      "status": "staging"
    },
    {
      "path": "metadata/query_spec.json",
      "kind": "file",
      "purpose": "Machine-readable batch-level deep-read input and output contract.",
      "generated_by_stage": "chatgpt_paper_deep_reading_skill_source",
      "status": "active"
    },
    {
      "path": "metadata/routing_status.json",
      "kind": "file",
      "purpose": "Routing state for the current deep-read workspace.",
      "generated_by_stage": "chatgpt_paper_deep_reading_skill_source",
      "status": "active"
    },
    {
      "path": "metadata/project_directory_annotations.json",
      "kind": "file",
      "purpose": "Editable enrichment rules for dynamic directory indexing.",
      "generated_by_stage": "chatgpt_paper_deep_reading_skill_source",
      "status": "active"
    },
    {
      "path": "reports/project_directory_index.md",
      "kind": "file",
      "purpose": "Human-facing directory map for routing and downstream graph building.",
      "generated_by_stage": "chatgpt_paper_deep_reading_skill_source",
      "status": "active"
    },
    {
      "path": "metadata/project_directory_index.json",
      "kind": "file",
      "purpose": "Machine-readable directory map for routing and downstream graph building.",
      "generated_by_stage": "chatgpt_paper_deep_reading_skill_source",
      "status": "active"
    }
  ],
  "status_overrides": [
    {
      "glob": "**/__pycache__/**",
      "status": "obsolete_or_ignored",
      "notes": "Python cache."
    },
    {
      "glob": "**/*.pyc",
      "status": "obsolete_or_ignored",
      "notes": "Python bytecode cache."
    }
  ]
}


path: schemas/project_directory_index_spec.md
content: # Project Directory Index Spec

The deep-read workspace must stay auditable.

Maintain:

- `metadata/project_directory_index.json`
- `reports/project_directory_index.md`
- `metadata/project_directory_annotations.json`

The index must identify authoritative per-paper reports, machine-readable intermediates, carried upstream source records or focus-spec snapshots, delivery-bundle and stage-delivery artifacts, visual artifacts still in use, and stale probe outputs that should be ignored.


path: schemas/research_generative_overlay.md
content: # Research-Generative Overlay For Paper Deep Reading

This overlay is now part of `paper_deep_reading_skill`. It must be applied **in addition to**, not instead of, all existing deep-reading, source-handling, report-contract, review-context, figure/table, formula-preservation, proof-to-practice, reviewer-audit, validation, and graph-handoff requirements.

## Non-Weakening Rule

- Never delete or weaken an existing `paper_deep_reading_skill` requirement to make room for this overlay.
- When there is tension between a shorter explanatory report and a more idea-generative report, choose the more idea-generative report.
- When there is tension between a safe factual claim and speculation about author intent, keep the factual claim safe and explicitly mark the author-side path as an evidence-backed reconstruction.
- When there is tension between generic future work and boundary-pushing research ideas, prioritize hidden-assumption-based and unavailable-mechanism-based idea generation.

## Core Lens

Read a paper as a reconstruction of the authors' possible design path:

\[
\text{Paper} = \text{Important Setting} + \text{Broken Assumption} + \text{Borrowed Tool} + \text{New Constraint} + \text{Surrogate Mechanism}.
\]

The strongest report should identify:

1. what mechanism was available in an easier setting;
2. why that mechanism becomes unavailable under the paper's target constraints;
3. what surrogate mechanism the authors invented;
4. how the narrative makes that surrogate feel inevitable;
5. which hidden assumptions of that surrogate can become new research ideas.

## Required Research-Generative Passes

### 1. Research Equation Pass

For every paper, extract the research equation:

\[
A(P) \cap \neg C \cap T \cap M \Rightarrow Z \approx Y.
\]

Where:

- \(A(P)\): an existing paradigm for an important problem;
- \(C\): a common assumption in prior work;
- \(\neg C\): the target setting where that assumption fails;
- \(T\): real-world constraints such as privacy, decentralization, non-IID data, limited labels, safety, latency, missing modalities, or limited compute;
- \(M\): a borrowed method family that almost works;
- \(Y\): the ideal mechanism that the borrowed method normally needs;
- \(Z\): the paper's constructed surrogate for \(Y\).

### 2. Author-Side Direction Discovery Pass

Reconstruct how the direction may have been found using this formula:

\[
\text{New Direction} = \text{Valuable Field} + \text{Painful Assumption} + \text{Emerging Tool} + \text{Unserved Setting}.
\]

Use careful language:

- "A plausible author-side thinking path is..."
- "The paper's setup suggests..."
- "The authors likely noticed..., but this is an inference rather than a factual claim about private thoughts."

### 3. Story-Construction Pass

Build a table:

| Challenge | Failure mode | Design principle | Module | Evidence |
|---|---|---|---|---|

Then identify whether the method is only a bag of modules:

\[
M_1 + M_2 + M_3
\]

or a closed loop:

\[
M_1 \Rightarrow M_2 \Rightarrow M_3 \Rightarrow M_1.
\]

### 4. Module Author-Thinking Pass

For every central module, use:

\[
M_i = \text{Failure} + \text{Unavailable Ideal Solution} + \text{Available Proxy} + \text{Design Choice} + \text{Assumption} + \text{Risk}.
\]

The report must say what each module is functionally replacing, not only what operation it performs.

### 5. Reverse Citation Logic Pass

For important citations or citation clusters, produce:

| Citation cluster | Narrative function | Assumption inherited | How this paper modifies it |
|---|---|---|---|

Common citation functions include field foundation, limitation paper, method ancestor, neighboring-field solution, strong baseline, benchmark protocol, implementation machinery, and negative contrast.

### 6. Experiments-As-Story-Evidence Pass

Read every experiment as:

\[
\text{Experiment} = \text{Claim} + \text{Counterfactual} + \text{Metric} + \text{Stress Condition}.
\]

State which alternative explanation each experiment rules out, which module it justifies, and whether the stress condition really tests the paper's claimed hard setting.

### 7. Reusable Story-Making Pattern Pass

Extract at least one reusable paper-making template, such as:

\[
A \text{ solves } P \text{ when } C; \quad T \Rightarrow \neg C; \quad M \text{ helps but requires } Y; \quad Y \notin T; \quad Z \approx Y.
\]

Also identify two-axis empty cells, replacement stories, and closed-loop contribution patterns when applicable.

### 8. Weakness-To-New-Idea Pass

Turn hidden assumptions into research directions:

\[
M_i \text{ works if } H_i \quad \Rightarrow \quad \text{New idea: make } M_i \text{ work under } \neg H_i.
\]

For each idea, state:

- violated hidden assumption;
- why the current paper is fragile there;
- what new mechanism would be needed;
- whether it is engineering follow-up, cross-domain transfer, or boundary-pushing research.

## Integrated Source

The overlay was merged from the following research-generative skill content, adapted so it strengthens rather than replaces `paper_deep_reading_skill`.

---

# Skill: Research-Generative Paper Reading

## Purpose

This skill turns a paper-reading task into a **research-generation exercise**.

It is designed for cases where the goal is not only to summarize a paper, but to infer:

- how the authors may have discovered the research direction;
- how they constructed the paper’s story;
- why each method module exists;
- why key related works were cited;
- what reusable “story-making” pattern the paper teaches;
- where future research opportunities and scientific boundary-pushing directions may lie.

The output should help a reader find **new research questions**, not merely understand the existing paper.

---

## Core Principle

Read the paper as if you are reconstructing the authors’ hidden design path.

Do not only ask:

> What did the paper do?

Instead ask:

> What sequence of observations, constraints, failures, borrowed ideas, and narrative choices could have led the authors to this work?

A strong reading should convert the paper from a static finished product into a dynamic reasoning trajectory.

---

## Recommended Output Structure

A high-quality report should usually contain the following sections:

1. One-sentence thesis of the paper
2. How the authors may have found this research direction
3. How the authors built the story
4. Method deep reading: the author-thinking behind each module
5. Why the key citations appear
6. How the experiments support the story
7. What story-making pattern is worth learning
8. Weaknesses, hidden assumptions, and fragile links
9. New research points and boundary-pushing directions
10. Final evaluation

Sections 2, 3, 4, 5, and 7 are the most important when the user asks for an author-perspective or research-inspiration reading.

---

# 1. First Pass: Identify the Paper’s Research Equation

Start by extracting the paper’s core research equation.

A useful template is:

\[
\text{Paper} =
\text{Important Setting}
+
\text{Broken Assumption}
+
\text{Borrowed Tool}
+
\text{New Constraint}
+
\text{Surrogate Mechanism}
\]

Or more explicitly:

\[
\text{Research Direction}
=
A(P)
\;\cap\;
\neg C
\;\cap\;
T
\;\cap\;
M
\]

Where:

- \(A(P)\): an existing paradigm \(A\) that solves an important problem \(P\);
- \(C\): a common assumption made by prior work;
- \(\neg C\): the paper’s target setting where this assumption fails;
- \(T\): a difficult real-world constraint, such as privacy, decentralization, non-IID data, low labels, latency, safety, limited compute, missing modalities, or distribution shift;
- \(M\): a method family that seems promising but cannot be directly applied.

The paper usually becomes interesting when:

\[
A \text{ is useful, but assumes } C;
\quad
T \text{ makes } C \text{ invalid};
\quad
M \text{ helps, but relies on } Y;
\quad
Y \text{ is unavailable under } T.
\]

Then the authors’ contribution often becomes:

\[
\text{Replace unavailable mechanism } Y
\text{ with new mechanism } Z.
\]

This gives a powerful reading lens:

> What unavailable mechanism did the authors replace?

Examples of unavailable mechanisms:

| Unavailable mechanism \(Y\) | Possible replacement \(Z\) |
|---|---|
| central server | neighbor consensus, peer graph, gossip update |
| labels | pseudo-labels, weak supervision, self-supervision |
| shared validation set | synthetic validation set, proxy risk, agreement score |
| global data | generated data, prototypes, public data, embeddings |
| trusted clients | reputation, uncertainty, robust aggregation |
| full communication | compression, event-triggered update, local caches |
| aligned modalities | contrastive bridges, latent anchors, adapters |

---

# 2. How the Authors May Have Found the Direction

This section should reconstruct the “research discovery path.”

Do not write it as a factual claim about the authors’ private thoughts. Write it as an evidence-based reconstruction:

> The authors likely noticed that...
>
> A plausible thinking path is...
>
> The paper’s setup suggests the following chain...

## 2.1 Direction-Finding Formula

Use this formula:

\[
\text{New Direction}
=
\text{Valuable Field}
+
\text{Painful Assumption}
+
\text{Emerging Tool}
+
\text{Unserved Setting}
\]

A strong paper often emerges from one of the following intersections:

\[
\text{Direction}
=
\text{Popular Paradigm}
\times
\text{Realistic Constraint}
\times
\text{Underexplored Failure Mode}
\]

or:

\[
\text{Direction}
=
\text{Method That Works Somewhere}
-
\text{Condition It Secretly Requires}
+
\text{Setting Where That Condition Fails}
\]

When reading, identify:

1. **The popular paradigm**  
   What research area is already important or active?

2. **The hidden assumption**  
   What does prior work quietly assume?

3. **The realistic violation**  
   In the real world, when does this assumption fail?

4. **The tempting borrowed method**  
   What existing technique almost solves the issue?

5. **The blocking constraint**  
   Why can’t that technique be directly used?

6. **The authors’ conceptual replacement**  
   What new mechanism plays the role of the missing piece?

## 2.2 Reconstructing the Authors’ Initial Observation

Many papers begin from a dissatisfaction:

\[
\text{Existing Work Works}
\quad
\text{but only when}
\quad
C_1, C_2, \ldots, C_k
\text{ hold.}
\]

The authors’ insight is often:

\[
\exists C_j
\quad
\text{such that}
\quad
C_j \text{ is unrealistic in the target setting.}
\]

Then the paper asks:

\[
\text{Can we retain the benefits of the old paradigm without } C_j?
\]

In the report, write this as:

> The authors likely started from the observation that prior work in \(A\) is attractive because it solves \(P\), but most methods assume \(C\). In the target setting \(T\), \(C\) is either unavailable, expensive, unsafe, or unrealistic. This creates a gap: how can one preserve the advantage of \(A\) while replacing \(C\) with a feasible proxy?

## 2.3 Look for the “Almost Works, But Not Quite” Method

A good research direction often comes from a method family that almost transfers.

Formula:

\[
M_{\text{source}}
\rightarrow
M_{\text{target}}
\quad
\text{fails because}
\quad
R_{\text{source}} \not\subseteq R_{\text{target}}
\]

Where:

- \(M_{\text{source}}\): method family that works in a source setting;
- \(M_{\text{target}}\): desired target setting;
- \(R_{\text{source}}\): requirements of the method;
- \(R_{\text{target}}\): resources allowed in the target setting.

Ask:

- What method from a neighboring field is being imported?
- What assumption prevents direct import?
- What local mechanism replaces the missing assumption?

Then write:

> The paper’s direction can be read as a transfer problem. The authors borrow \(M\) from a setting where resource \(Y\) exists. But in the target setting, \(Y\) is prohibited or absent. The paper’s main idea is therefore to construct \(Z\), a surrogate for \(Y\), using only resources allowed in the target setting.

## 2.4 Infer the Inspiration Source

Authors often draw inspiration from 3 layers:

\[
\text{Inspiration}
=
\text{Problem Pressure}
+
\text{Method Analogy}
+
\text{System Constraint}
\]

For each major contribution, ask:

| Question | What to infer |
|---|---|
| What failure did the authors repeatedly emphasize? | Problem pressure |
| What prior method is structurally similar? | Method analogy |
| What is disallowed in the setting? | System constraint |
| What replacement signal is available? | Design source |
| What did the authors make consensus over? | Story core |

A good report should explicitly state:

> The likely inspiration was not simply “use method \(M\),” but “method \(M\) normally depends on \(Y\); since \(Y\) is unavailable, create \(Z\) that plays the same functional role.”

---

# 3. How the Authors Built the Story

This section explains the narrative construction of the paper.

A paper’s story usually follows this pattern:

\[
\text{Story}
=
\text{Problem Importance}
+
\text{Prior Success}
+
\text{Unrealistic Assumption}
+
\text{New Setting}
+
\text{Specific Failure Modes}
+
\text{Mechanisms}
+
\text{Evidence}
\]

## 3.1 The Gap-to-Mechanism Bridge

The best papers do not present modules as arbitrary engineering. Each module answers one named failure.

Use this mapping:

\[
\text{Challenge}_i
\rightarrow
\text{Failure Mode}_i
\rightarrow
\text{Design Principle}_i
\rightarrow
\text{Module}_i
\rightarrow
\text{Ablation}_i
\]

A strong report should reconstruct this table.

| Story element | Reading question |
|---|---|
| Challenge | What breaks in the new setting? |
| Failure mode | Why do existing methods fail? |
| Design principle | What kind of signal could repair it? |
| Module | What mechanism implements that signal? |
| Ablation | What experiment proves this module was needed? |

If a paper has three modules, look for a “three-challenge, three-mechanism, three-ablation” structure:

\[
(C_1, C_2, C_3)
\rightarrow
(M_1, M_2, M_3)
\rightarrow
(A_1, A_2, A_3)
\]

This structure makes the paper easy to defend.

## 3.2 The Narrative Escalation Pattern

Many good papers escalate the problem in stages.

Template:

1. **Base setting is important.**
2. **But the standard assumption fails.**
3. **A known solution family seems relevant.**
4. **But it fails under the new constraints.**
5. **This creates several concrete sub-problems.**
6. **Each sub-problem motivates one module.**
7. **The modules form a closed loop.**
8. **Experiments validate the full loop and each part.**

In formula form:

\[
P
\rightarrow
A_{\text{old}}
\rightarrow
\neg C
\rightarrow
M_{\text{candidate}}
\rightarrow
\neg R
\rightarrow
\{F_i\}_{i=1}^{k}
\rightarrow
\{Z_i\}_{i=1}^{k}
\rightarrow
\text{Empirical Closure}
\]

Where:

- \(P\): important problem;
- \(A_{\text{old}}\): existing paradigm;
- \(\neg C\): broken assumption;
- \(M_{\text{candidate}}\): tempting method family;
- \(\neg R\): missing resource or violated requirement;
- \(F_i\): failure modes;
- \(Z_i\): proposed modules.

## 3.3 Closed-Loop Story Design

The strongest method stories are not a list of modules. They are loops.

A weak story looks like:

\[
M_1 + M_2 + M_3
\]

A strong story looks like:

\[
M_1 \Rightarrow M_2 \Rightarrow M_3 \Rightarrow M_1
\]

or:

\[
\text{Signal}
\rightarrow
\text{Data}
\rightarrow
\text{Model}
\rightarrow
\text{Better Signal}
\]

When reading, ask:

- Does Module 1 produce something Module 2 needs?
- Does Module 2 create a resource Module 3 uses?
- Does Module 3 improve the condition under which Module 1 works?
- Is there a conceptual object that flows through all modules?

Common flowing objects:

| Flowing object | Typical story |
|---|---|
| pseudo-label | confidence improves training |
| generated data | data improves validation or augmentation |
| graph consensus | neighbors improve local estimates |
| uncertainty | filtering improves reliability |
| prototypes | shared representation without raw data |
| rewards | policy improves data collection |
| memory | past experience stabilizes current learning |

Write the story as:

> The paper is not merely stacking modules. It constructs a loop: \(M_1\) creates \(S\), \(M_2\) improves or expands \(S\), and \(M_3\) uses \(S\) to make the global system more reliable. This makes the contribution feel coherent rather than additive.

---

# 4. Method Deep Reading: The Author-Thinking Behind Each Module

This is the heart of an author-perspective report.

For every method module, reconstruct the likely thought process using the following template.

## 4.1 Module Reading Template

For module \(M_i\), answer:

\[
M_i =
\text{Failure}
+
\text{Unavailable Ideal Solution}
+
\text{Available Proxy}
+
\text{Design Choice}
+
\text{Assumption}
+
\text{Risk}
\]

Expanded:

1. **Failure being fixed**  
   What would go wrong without this module?

2. **Ideal but unavailable solution**  
   What would solve the problem if constraints did not exist?

3. **Available proxy**  
   What signal/resource is still allowed?

4. **Design choice**  
   How does the module turn that proxy into a usable mechanism?

5. **Assumption**  
   Under what condition does this module work?

6. **Risk or failure case**  
   When might the module fail?

7. **Evidence**  
   What ablation or analysis should prove it matters?

## 4.2 Functional Role Formula

Do not describe a module only by its operations. Describe its functional role.

\[
\text{Module}
=
\text{Operation}
\quad
\text{serving the role of}
\quad
\text{Missing Mechanism}
\]

Examples:

| Operation | Functional role |
|---|---|
| neighbor averaging | replaces central aggregation |
| pseudo-labeling | replaces missing labels |
| data augmentation | replaces data diversity |
| synthetic validation | replaces shared validation set |
| confidence threshold | replaces oracle correctness check |
| clustering | replaces known client groups |
| uncertainty estimation | replaces ground-truth reliability |
| contrastive alignment | replaces paired modalities |
| distillation | replaces direct data sharing |

The report should say:

> This module should be read not as a technical trick, but as a surrogate for \(Y\), the mechanism that would have been available in an easier version of the problem.

## 4.3 Reverse-Engineering the Design Choice

For each design choice, ask:

\[
\text{Why this design rather than the simplest baseline?}
\]

A useful ladder:

1. **Naive local solution**  
   What is the simplest local-only method?

2. **Why it fails**  
   What bias, variance, instability, privacy issue, or compute issue appears?

3. **First improvement**  
   What extra signal can reduce the failure?

4. **Why the improvement is still insufficient**  
   Does it create imbalance, noise, cost, or new assumptions?

5. **Final design**  
   What extra correction makes the method robust enough?

This often reveals the authors’ actual design logic:

\[
\text{Naive}
\rightarrow
\text{Failure}
\rightarrow
\text{Borrowed Fix}
\rightarrow
\text{Constraint Violation}
\rightarrow
\text{Adapted Fix}
\]

## 4.4 Find the Hidden “Equivalent Ideal”

Most modules approximate an ideal object that is unavailable.

Use this question:

> If the authors had unlimited access, what would they use instead?

Then map:

\[
\text{Unavailable Ideal } I
\approx
\text{Constructed Proxy } \hat{I}
\]

Examples:

| Unavailable ideal \(I\) | Constructed proxy \(\hat{I}\) |
|---|---|
| true labels | pseudo-labels |
| global data distribution | generated data distribution |
| central validation set | synthetic validation set |
| oracle client reliability | performance on proxy data |
| true domain alignment | feature-level agreement |
| full gradients | compressed gradients |
| trusted server | consensus protocol |
| clean dataset | robust filtering |

In the report, state:

> The module makes sense once we see it as an approximation of \(I\). Its novelty is not merely in computing \(\hat{I}\), but in computing \(\hat{I}\) under the constraints of the paper’s target setting.

## 4.5 Identify the Module’s Fragile Assumption

Every clever module has a hidden bet.

Formula:

\[
M_i \text{ works if } H_i \text{ holds.}
\]

Examples:

- pseudo-labeling works if confidence correlates with correctness;
- neighbor consensus works if neighbors provide complementary rather than adversarial signals;
- synthetic data works if the generator covers the relevant distribution;
- adaptive aggregation works if proxy validation performance correlates with real performance;
- contrastive alignment works if positives are semantically aligned;
- personalization works if client-specific structure is stable.

A strong report should include:

> The module’s hidden assumption is \(H_i\). This is also a natural future research point, because if \(H_i\) fails, the paper’s mechanism may break.

This turns method reading into research generation.

---

# 5. Why Key Citations Appear: Reverse Citation Logic

Do not treat citations as a bibliography list. Treat them as narrative functions.

A citation usually appears because it gives the authors permission to make one of the following moves:

\[
\text{Citation}
\Rightarrow
\text{Narrative Permission}
\]

## 5.1 Citation Function Taxonomy

| Citation type | Function in the story | What to write in the report |
|---|---|---|
| Foundational paradigm | Establishes the field and importance | “This citation anchors the paper in \(A\).” |
| Limitation paper | Shows known weakness or gap | “This supports the claim that \(A\) struggles under \(T\).” |
| Method ancestor | Provides a tool later adapted | “This is the technical ancestor of module \(M_i\).” |
| Neighboring-field solution | Shows transfer inspiration | “The authors borrow the logic of \(M\), but remove its reliance on \(Y\).” |
| Strong baseline | Raises comparison pressure | “This baseline defines what the new method must beat.” |
| Benchmark protocol | Legitimizes experimental setup | “This citation justifies dataset split, non-IID construction, metric, or architecture.” |
| Implementation detail | Provides technical machinery | “This citation enables the practical realization of a submodule.” |
| Negative contrast | Shows what prior work cannot handle | “This citation is used to draw the boundary of the new contribution.” |

## 5.2 Citation Reverse-Engineering Formula

For each important cited work \(W\), infer:

\[
W
\rightarrow
\{\text{Problem}, \text{Tool}, \text{Assumption}, \text{Limitation}, \text{Borrowed Element}\}
\]

Then write:

\[
\text{Authors cite } W
\text{ not merely because } W \text{ is related,}
\text{ but because } W \text{ supplies } X
\text{ while leaving gap } G.
\]

Example phrasing:

> This citation functions as a method ancestor. The paper inherits the idea of \(X\), but the target setting lacks \(Y\), so the authors redesign \(X\) into \(X'\).

or:

> This citation functions as a contrastive boundary. It shows that prior work can solve the problem when \(C\) holds, which helps the authors justify why their setting, where \(C\) does not hold, deserves a new method.

## 5.3 Build a Citation-to-Module Map

For the report, create a table:

| Citation cluster | What it contributes | What assumption it carries | How this paper modifies it |
|---|---|---|---|
| Field foundation | Importance of \(P\) | Usually assumes \(C\) | Paper removes \(C\) |
| Method family | Tool \(M\) | Requires \(Y\) | Paper replaces \(Y\) with \(Z\) |
| Closest prior work | Baseline solution | Does not handle \(T\) | Paper adapts to \(T\) |
| Technical machinery | Algorithmic component | Works in original setting | Paper embeds it into new system |
| Experimental precedent | Protocol or metric | Benchmark convention | Paper follows or extends it |

This is especially useful for explaining why some references are “key” while others are background.

## 5.4 Detect the Citation Storyline

A paper’s related work often secretly says:

\[
\text{People solved } P \text{ under } C_1;
\quad
\text{others solved } P \text{ under } C_2;
\quad
\text{but nobody solved } P \text{ under } \neg C_1 \cap \neg C_2.
\]

This creates the opening for the paper.

Write this as:

> The related work is not just listing fields. It constructs a coordinate system. One axis is \(A\), another is \(T\), and the paper positions itself in the empty cell where both constraints must be handled simultaneously.

---

# 6. Experiments as Story Evidence

Experiments should be read as narrative proof.

A useful formula:

\[
\text{Experiment}
=
\text{Claim}
+
\text{Counterfactual}
+
\text{Metric}
+
\text{Stress Condition}
\]

For each experiment, ask:

1. What claim does this experiment support?
2. What alternative explanation does it rule out?
3. What stress condition makes the result meaningful?
4. Which module does it justify?
5. Does the ablation align with the method story?

## 6.1 Main Result

Main results usually answer:

\[
\text{Does the complete system outperform prior solutions under the target setting?}
\]

Look for:

- low-resource regimes;
- high heterogeneity;
- distribution shift;
- privacy constraints;
- adversarial or noisy conditions;
- scalability.

## 6.2 Ablation

Ablation should map back to modules:

\[
M_i \text{ removed}
\Rightarrow
\text{performance drop}
\Rightarrow
\text{module necessity}
\]

A strong report should say whether the ablation truly proves the module’s narrative role.

## 6.3 Stress Tests

Stress tests show whether the paper’s central idea survives when the target difficulty increases.

Examples:

- fewer labels;
- stronger non-IID;
- fewer clients;
- weaker graph connectivity;
- noisier labels;
- worse generator;
- lower compute;
- malicious clients;
- domain shift.

Use this reading:

\[
\text{If the paper claims to solve } T,
\text{ then experiments should vary the intensity of } T.
\]

---

# 7. What Story-Making Pattern Is Worth Learning

This section should extract a reusable storytelling template from the paper.

The goal is to teach the reader how to build future papers.

## 7.1 General Story Template

A strong research story can often be expressed as:

\[
\boxed{
\text{Old Success}
+
\text{New Reality}
\Rightarrow
\text{Old Assumption Breaks}
\Rightarrow
\text{Known Tool Almost Works}
\Rightarrow
\text{Constraint Blocks Direct Use}
\Rightarrow
\text{New Surrogate Mechanism}
}
\]

More concretely:

\[
\boxed{
A \text{ solves } P \text{ when } C \text{ holds;}
\quad
T \text{ makes } C \text{ invalid;}
\quad
M \text{ can address } \neg C \text{ but requires } Y;
\quad
Y \notin T;
\quad
\text{therefore we design } Z \approx Y.
}
\]

This is one of the most useful formulas for generating new research ideas.

## 7.2 Three-Module Story Template

Many system or algorithm papers can be built as:

\[
\boxed{
F_1 \rightarrow M_1,\quad
F_2 \rightarrow M_2,\quad
F_3 \rightarrow M_3
}
\]

Where:

- \(F_1\): signal reliability failure;
- \(F_2\): data or representation insufficiency;
- \(F_3\): coordination, selection, or optimization failure.

Then:

\[
M_1 \text{ repairs signal}
\]
\[
M_2 \text{ expands information}
\]
\[
M_3 \text{ coordinates the system}
\]

A particularly elegant story is:

\[
M_1 \Rightarrow M_2 \Rightarrow M_3
\]

rather than:

\[
M_1 + M_2 + M_3.
\]

In prose:

> The first module creates a usable signal. The second module enriches or stabilizes that signal. The third module uses the improved signal to coordinate the whole system.

## 7.3 Replacement Story Template

Another powerful pattern is the replacement story:

\[
\text{In easy setting: }
Y \text{ is available.}
\]
\[
\text{In hard setting: }
Y \text{ is unavailable.}
\]
\[
\text{Our idea: }
Z \text{ plays the role of } Y \text{ without violating constraints.}
\]

Examples:

| Easy-setting resource \(Y\) | Hard-setting replacement \(Z\) |
|---|---|
| labels | pseudo-labels |
| server | peer consensus |
| public dataset | generated data |
| validation set | proxy validation |
| oracle confidence | calibrated uncertainty |
| clean clients | robust reputation |
| full communication | sparse communication |
| paired data | contrastive alignment |

This is often the deepest “paper-making” logic.

## 7.4 Two-Axis Empty Cell Template

Position the paper as filling an empty cell:

\[
\text{Axis 1: Problem condition}
\]
\[
\text{Axis 2: System constraint}
\]

Create a table:

|  | Easy system | Hard system |
|---|---|---|
| Easy data | solved | partly solved |
| Hard data | partly solved | **your paper** |

The story becomes:

> Prior work solves each difficulty separately, but the intersection remains underexplored.

Formula:

\[
\text{Contribution}
=
\text{Difficulty}_1
\cap
\text{Difficulty}_2
\cap
\cdots
\cap
\text{Difficulty}_k
\]

This is especially useful for papers combining:

- privacy + low labels;
- decentralization + non-IID;
- robustness + personalization;
- multimodality + missing data;
- long context + low latency;
- safety + autonomy;
- fairness + distribution shift.

## 7.5 Closed-Loop Contribution Template

The most memorable papers often create a loop:

\[
\boxed{
\text{Noisy Signal}
\rightarrow
\text{Proxy Resource}
\rightarrow
\text{Better Coordination}
\rightarrow
\text{Cleaner Signal}
}
\]

or:

\[
\boxed{
\text{Weak Supervision}
\rightarrow
\text{Representation Improvement}
\rightarrow
\text{Reliability Estimation}
\rightarrow
\text{Better Weak Supervision}
}
\]

When writing the report, identify the loop and state:

> The paper’s contribution is not a bag of tricks. It constructs a feedback loop in which the output of one module becomes the missing resource required by the next module.

## 7.6 Boundary-Pushing Template

Convert hidden assumptions into future research.

For each module:

\[
M_i \text{ works if } H_i.
\]

Then future work is:

\[
\text{New Research Direction}
=
\text{Make } M_i \text{ work when } \neg H_i.
\]

Examples:

| Current hidden assumption \(H_i\) | Future direction \(\neg H_i\) |
|---|---|
| neighbors are helpful | malicious or untrusted neighbors |
| confidence is calibrated | overconfident wrong predictions |
| generator covers distribution | biased or low-quality generator |
| proxy metric matches true metric | proxy-real mismatch |
| graph is fixed | learnable or dynamic topology |
| clients share label space | partial or open-set labels |
| data is stationary | temporal drift |
| compute is sufficient | resource-constrained deployment |

This is one of the best ways to turn a reading report into a research proposal.

---

# 8. Weakness and Breakthrough Analysis

A good report should not only praise the paper. It should expose the scientific frontier.

Use the following formula:

\[
\text{Weakness}
=
\text{Claim}
-
\text{Evidence}
+
\text{Hidden Assumption}
\]

For each key claim, ask:

1. What evidence supports it?
2. What evidence is missing?
3. What assumption is required?
4. What happens if the assumption fails?
5. Can that failure become a new paper?

## 8.1 Common Weakness Categories

| Category | Questions |
|---|---|
| Theory | Is there convergence, risk, bias, or generalization analysis? |
| Scalability | Does the method scale to larger data, models, clients, or modalities? |
| Robustness | What if clients are noisy, malicious, or unreliable? |
| Privacy | Does the method leak through gradients, models, synthetic data, or statistics? |
| Compute | Is the method realistic for edge devices? |
| Evaluation | Are benchmarks too simple or too clean? |
| Proxy mismatch | Does the proxy signal really match the target objective? |
| Ablation depth | Do ablations isolate mechanisms or only show performance differences? |
| Assumption realism | Are clients, labels, topology, or distributions realistic? |

## 8.2 Convert Weaknesses into Research Directions

Use:

\[
\text{Future Work}
=
\text{Current Method}
+
\text{Violated Assumption}
+
\text{New Mechanism}
\]

Example phrasing:

> The paper assumes \(H\). A natural next step is to study the setting where \(H\) fails. This would require replacing \(M\)'s reliance on \(H\) with a more robust mechanism such as \(Z\).

---

# 9. Writing Style for the Report

The report should sound like a research mentor explaining how the paper was probably invented.

Use phrases such as:

- “A plausible author-side thinking path is...”
- “This module is best understood as a surrogate for...”
- “The citation is not ornamental; it plays the role of...”
- “The story can be compressed into the formula...”
- “The hidden bet of this module is...”
- “This weakness can be converted into a new research question...”
- “The paper’s deepest lesson is not the specific technique, but the replacement pattern...”

Avoid:

- simply listing sections;
- repeating the abstract;
- describing equations without explaining why they were needed;
- treating citations as background only;
- giving future work that is too generic;
- claiming to know the authors’ private thoughts with certainty.

---

# 10. Final Report Skeleton

Use this skeleton when producing the final answer.

```markdown
# Paper Deep Reading Report

## 1. One-Sentence Thesis

This paper can be read as solving:

\[
A \text{ works under } C,\quad
T \text{ breaks } C,\quad
M \text{ almost helps but requires } Y,\quad
\text{so the paper designs } Z.
\]

## 2. How the Authors May Have Found This Direction

### 2.1 The likely starting dissatisfaction
...

### 2.2 The transfer that almost worked
...

### 2.3 The unavailable mechanism
...

### 2.4 The replacement mechanism
...

### 2.5 Research-direction formula
\[
\text{Direction} =
\text{Popular paradigm}
+
\text{Broken assumption}
+
\text{Hard setting}
+
\text{Surrogate mechanism}
\]

## 3. How the Authors Built the Story

### 3.1 Challenge-to-module map

| Challenge | Failure mode | Design principle | Module | Evidence |
|---|---|---|---|---|

### 3.2 Narrative escalation
...

### 3.3 Closed-loop story
...

## 4. Method Deep Reading

For each module:

### Module \(M_i\)

| Lens | Interpretation |
|---|---|
| Failure fixed | ... |
| Ideal unavailable solution | ... |
| Available proxy | ... |
| Design choice | ... |
| Hidden assumption | ... |
| Possible failure | ... |
| Future research point | ... |

## 5. Why the Key Citations Appear

| Citation cluster | Narrative function | Assumption inherited | How the paper modifies it |
|---|---|---|---|

## 6. Experiments as Story Evidence

...

## 7. Story-Making Pattern Worth Learning

\[
A \text{ solves } P \text{ when } C;
\quad
T \Rightarrow \neg C;
\quad
M \text{ helps but requires } Y;
\quad
Y \notin T;
\quad
Z \approx Y.
\]

...

## 8. Weaknesses and Boundary-Pushing Directions

| Hidden assumption | Why it matters | New research direction |
|---|---|---|

## 9. Final Evaluation

...
```

---

# 11. Quality Checklist

Before finalizing the report, check:

- Did I explain how the authors may have discovered the direction?
- Did I identify the broken assumption?
- Did I identify the unavailable ideal mechanism?
- Did I explain the replacement mechanism?
- Did I map every major module to a concrete failure mode?
- Did I explain why key citations appear?
- Did I extract a reusable story-making formula?
- Did I convert hidden assumptions into future research ideas?
- Did I avoid claiming certainty about private author intentions?
- Did I help the reader generate new research directions?

---

# 12. Compact Mental Model

The entire skill can be compressed into this one line:

\[
\boxed{
\text{Read a paper as: }
\text{What was impossible under the new constraints,}
\text{what surrogate did the authors invent,}
\text{and how did they make that surrogate look inevitable?}
}
\]

A deep report should reveal not only the paper’s contribution, but the **research-making grammar** behind it.



path: schemas/routing_status_template.json
content: {
  "updated_at": "",
  "skill_name": "paper-deepread-comic-studio",
  "current_stage": "",
  "next_stage": "",
  "possible_user_inputs_for_next_stage": [],
  "deepread_policy": "every paper in the batch manifest must receive one authoritative detailed report before handoff",
  "required_paper_count": 0,
  "remaining_papers_without_authoritative_reports": [],
  "stage_delivery_report": "reports/stage_delivery_handoff.md",
  "resume_from_bundle_only_supported": true,
  "delivery_bundle_zip": "",
  "status_artifacts": [],
  "directory_description_artifacts": [],
  "authoritative_handoff_artifacts": [],
  "last_user_request": "",
  "last_assistant_action": "",
  "completed_stages": [],
  "routing_tags": [],
  "paper_id": "",
  "paper_title": "",
  "key_artifacts": [],
  "blockers": []
}


path: schemas/sources_refresh_templates.md
content: # Sources Refresh Templates

## When newly generated outputs are needed later

请把以下文件重新打包成一个 zip 并上传到当前 Project `sources`：

- `generated/visuals/`
- `generated/intermediate/`
- `generated/teaching/`（如果生成了讲解/PPT/Q&A衍生材料）
- `generated/routing/`

目录结构请遵循 `schemas/sources_zip_layout.md`。上传完成后，请明确回复“已上传完成”，我再继续下一步。


path: schemas/sources_zip_layout.md
content: # Sources Zip Layout

Use a single zip bundle with folders like:

- `papers/main/`
- `reviews/openreview/`
- `supplementary/`
- `generated/visuals/`
- `generated/intermediate/`
- `generated/teaching/`
- `generated/routing/`
- `reports/per_paper/`
- `reports/stage_delivery_handoff.md`
- `metadata/delivery_bundle_manifest.json`
- `metadata/routing_status.json`
- `metadata/project_directory_annotations.json`
- `metadata/project_directory_index.json`
- `metadata/paper_batch_manifest.json`
- `reports/project_directory_index.md`

If ChatGPT needs page images or visual manifests, put them under `generated/visuals/`.

Prefer one detailed report per paper under `reports/per_paper/<paper-slug>/`.

For a fresh session to continue from this bundle alone, also keep:

- one per-paper `metadata/source_record.json` snapshot or the equivalent `metadata/focus_specs/<paper-slug>.json`
- `reports/stage_delivery_handoff.md`
- `metadata/delivery_bundle_manifest.json`
- `metadata/routing_status.json`
- `metadata/project_directory_index.json`
- `reports/project_directory_index.md`

The next stage should read those files before scanning the tree ad hoc.

Teaching materials under `generated/teaching/` are derivative sidecars for explanation, Q&A, role-play discussion, and slide blueprints. They must point back to the authoritative detailed report.


path: schemas/teaching_explanation_overlay.md
content: # Teaching-Explanation Overlay

This overlay turns a rigorous paper deep-read into material that can be taught, discussed, and defended.
It is a non-weakening overlay: every original deep-read, formula-preservation, proof-to-practice, figure/table, reviewer, OpenReview, research-generative, validation, and handoff requirement remains mandatory.

## Core principle

A paper is ready to teach only when the reader can answer five questions without hiding the hard parts:

1. What problem did the paper make important?
2. What assumption breaks in the target setting?
3. What ideal mechanism would solve the problem but is unavailable?
4. What surrogate mechanism does the paper build?
5. Which evidence supports the surrogate, and where can it fail?

Every key concept should be taught in the same four-step order:

```text
直觉 -> 数学公式或 formal definition -> 具体例子 -> 局限 / failure case
```

For complex modules, the teaching explanation must still name inputs, outputs, symbols, dimensions, training parameters, fixed hyperparameters, and training-vs-inference data flow. Simplify the language, not the factual content.

## Teaching equation

Use the same research equation, but translate it for a listener:

```text
Old success: A(P) works under assumption C.
New reality: target constraint T makes C false.
Almost-useful tool: method family M could help but needs unavailable mechanism Y.
Paper move: construct surrogate Z.
Evidence question: does Z behave enough like Y under the actual stress setting?
```

## Required teaching deliverables inside the authoritative report

### 1. Audience map

| Audience | Prior knowledge | Likely confusion | Best entry point | Math depth | Evidence needed |
|---|---|---|---|---|---|

### 2. Three-layer summary

- 30 seconds: one vivid, accurate story.
- 3 minutes: problem -> failed assumption -> core idea -> evidence -> caveat.
- 10 minutes: add method modules, key formula, main experiments, and limitations.

### 3. Story spine

```text
Before -> Pain -> Failed old assumption -> Key replacement -> Mechanism -> Evidence -> Caveat -> Next idea
```

### 4. Formula teaching table

| Formula | Plain-language purpose | Term-by-term explanation | Verbal script | Algorithm role | Fragility |
|---|---|---|---|---|---|

### 5. Figure/table teaching table

| Visual | First thing to point at | Claim supported | Misreading risk | What remains unclear | Verbal script |
|---|---|---|---|---|---|

### 6. Experiment teaching unit

For each experiment block:

- Question answered:
- Skeptical objection addressed:
- Setup/baselines/metrics:
- Expected result if claim is true:
- Actual result:
- What it proves:
- What it does not prove:
- One-sentence explanation of the table/curve:

### 7. Role-play discussion pack

| Role | Checks | Output |
|---|---|---|
| Archaeologist | ancestry and prior-work relation | cited ancestor, inherited assumption, modification |
| Bug Hunter | rigor and reproducibility | attack questions, likely author response |
| Researcher | future scientific value | follow-up projects and boundary idea |
| Industry Practitioner | deployability | adoption conditions and practical risk |
| Social Impact Assessor | broader impacts | positive and negative impacts |
| Author Defender | acceptance logic | strongest pitch and weakest claim |
| Teacher | learnability | analogy, prerequisites, teachback questions |

### 8. Q&A bank

| Question | Audience | Evidence-backed answer | Confidence | Report section / paper evidence |
|---|---|---|---|---|

### 9. Misunderstanding guardrails

- The paper does not claim:
- The analogy breaks when:
- The result should not be generalized to:
- The easiest-to-overinterpret baseline/result is:
- The limitation that must be stated aloud is:

### 10. Slide / talk blueprint

| Slide | Title | One-sentence point | Visual/formula | Speaker notes | Transition | Likely question |
|---|---|---|---|---|---|---|

### 11. Teachback self-test

Include 8-12 questions covering setting, assumption, method dataflow, formula, evidence, limitation, reviewer attack, and future direction.

### 12. Complete numeric training-to-inference example

Include one tiny numeric example that follows the method from input construction through a training loss/update and then through one inference decision. Mark any simplified toy values that are not paper-explicit.

## Output policy

The authoritative detailed report remains the single source of truth. Optional teaching sidecars may be generated, but only as derivatives from the authoritative report:

- `generated/teaching/<paper-slug>/teaching_outline_cn.md`
- `generated/teaching/<paper-slug>/slide_blueprint_cn.json`
- `generated/teaching/<paper-slug>/qa_bank_cn.json`
- `generated/teaching/<paper-slug>/role_play_discussion_pack_cn.md`

Sidecars must not introduce new unsupported claims.


path: schemas/teaching_explanation_spec.template.json
content: {
  "paper_id": "string",
  "paper_title": "string",
  "audience_profile": {
    "primary_audience": "technically literate graduate student outside the narrow subfield",
    "secondary_audience": "skeptical reviewer or advisor",
    "beginner_prerequisites": [],
    "likely_confusions": [],
    "math_depth": "intuition | mechanism | full"
  },
  "three_layer_summary": {
    "thirty_seconds": "",
    "three_minutes": "",
    "ten_minutes": ""
  },
  "story_spine": {
    "before": "",
    "pain": "",
    "broken_assumption": "",
    "key_replacement": "",
    "mechanism": "",
    "evidence": "",
    "caveat": "",
    "next_idea": ""
  },
  "formula_teaching": [],
  "visual_teaching": [],
  "experiment_teaching": [],
  "role_play_discussion_pack": [],
  "qa_bank": [],
  "misunderstanding_guardrails": [],
  "slide_blueprint": [],
  "teachback_self_test": [],
  "three_takeaways": []
}

Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (HIGH)