progressive-investment-research

Cumulative Investment Research

The goal of this Skill is not to write one more report, but to make every research session advance the same controllable cognition model.

The core artifact is a dossier: a set of lightweight Markdown files that record the current model, evidence, conflicts, open questions, and judgment changes for a given research subject. Reports, memos, indexes, search results, and Obsidian notes are all derived outputs, not the model itself.

Core Definitions

Model = the actionable cognitive state of the current research subject.

It answers: how do we currently see things, what do we know, what do we not know, where are the conflicts, and what is most worth verifying next. It must be quickly recoverable by humans, not just AI-friendly.

context.md is the continuation entry point, recording why this dossier / workspace exists, which skill is used by default, where to resume from, and which writes trigger the need for user confirmation. It is not the factual source of research conclusions, nor does it need to be updated in every round of discussion. When the user is just asking questions, testing ideas, or discussing mechanisms, answer and clarify first; only change it on cold start, when continuation cost is high, when the research boundary/entry point changes, or when the user explicitly requests "write/update context".current-synthesis.md remains the human entry point to the research model, with the title using # Current Model. When the user asks "what is the current state," "what do we know," or "what is the model," read it first, then read context.md、model-map.md、open-questions.md and related modules as needed.

Numbers and models are also part of the factual source.

Key numbers in research materials cannot merely be compressed into textual judgments. When encountering numbers such as revenue, CapEx, price, capacity, share, MAU, tokens, utilization, gross margin, depreciation, payback period, yield, delivery cycle, etc., record the source, source type, review status, and purpose. Especially for numbers that do not look like something ordinary public search could easily obtain, increase sensitivity: indicate whether it comes from user material, company disclosure, derived material, estimation, or agent inference, and do not disguise it as a public fact.

Calculation models are first-class artifacts. Whenever a judgment depends on formulas, parameters, back-calculation, sensitivity, or cross-layer transmission, consider building a lightweight model in models/ or recording a model backlog in the module. Modeling is not for precision, but for exposing assumptions, units, dependencies, blockers, and disproof conditions.

Design Principles

Practicality First

Research work is complex, but the workflow should be simple. Do not create directories, files, state machines, or team records for the sake of completeness. Any newly added file must directly serve one of: recovering the current model, tracking important judgments, preserving stable modules, recording open questions, or executing promote.

Human Controllability

Users must not be forced to trust a pile of scattered md files. At the end of a phase of work, output or update the current state: one-sentence judgment, what was processed this round, model changes, the most important unknowns, risks, and unprocessed materials.

When a round of substantive research is completed, the model judgment changes, or the user requests "detailed report / phase report / must report to me in detail when done," you must use references/output-formats.md in Stage Research Report Standard: Even if the user does not open any md, they should be able to fully understand the research objectives, methods, evidence, reasoning, conclusions, evidence boundaries, relationship to other research modules, disconfirming conditions, actual file changes, and verification results. Do not just deliver a file change list.

Important Signals and Important Assumptions Registry

When the research progresses to signals or assumptions that will repeatedly affect investment judgment, they must be separately consolidated into a readable entry point, with the default filename modules/important-signals-assumptions.md. It is not a new canonical source of calculation facts, but an index/reading layer:

• The relationship to the source file must be clearly marked: which is the canonical source, models/、modules/ or frameworks/ file.
• The source row_id or a stable section name must be cited, for example CP-SIG-*、RPP-IN-*、PWM-HC-*。
• A second set of numerical conventions must not be created in that file; when the source model changes, first change the source model, then sync the registry.
• Collect only a small number of P0/P1 signals and assumptions that would change conclusions; do not move all calculation rows into it.

Default structure:

# Important Signals and Assumptions Registry

## Relationship to Source Files
| registry section | canonical source | relationship |

## P0 Signals
| signal_id | signal | current read | source rows | why it matters | reversal / action |

## P0 Assumptions
| assumption_id | assumption | current value / range | source rows | sensitivity | what would invalidate it |

When the user asks "what signals count as a reversal," "what are the core assumptions," "which numbers are most sensitive," or "what should be continuously tracked going forward," check this registry first, then go back to the source model.

Company Pages / Company Watchlist

When the research advances from the industry chain to specific trackable companies, or the user requests "company section / one independent md per company / whether it is a holding or watchlist / entry point / what conditions must be met before buying," by default create or update under the dossier companies/<company-slug>.md. A company page is not a company profile, but an investment candidate card; it must cite models/、modules/ or factual anchors in public disclosures, and must not create a second set of numerical conventions.

A company page must at least answer:

• What we know: key facts such as revenue, profit, gross margin, orders, capacity, customers, price, market cap, etc., with sources and row_id marked.
• Current status: one ofholding、watchlist、candidate、monitor、avoid ; when holding status is uncertain, write 未确认, and do not pretend to hold or be flat.
• Why we are watching: which industry assumption or bottleneck chain it validates.
• Core assumptions: which business variables the buy thesis depends on; which have been validated and which remain open.
• Disconfirming conditions: what would cause downgrade, removal, or a ban on adding to the position.
• Entry discipline: if the core business assumptions remain unchanged, under what valuation/price/scenario to enter deep buy evaluation; distinguish static convention from forward convention.
• Monitoring checklist: which variables to refresh at each earnings report or major announcement.

Market data such as price, market cap, PE, PB, and dividend yield are high-drift data. When writing into a company page, the snapshot date and needs refresh before trademust be marked; before trading, they must be refreshed again, and old quotes must not be treated as current prices.

If a price judgment depends on a formula, for example 可接受市值 = forward 扣非利润 × 目标 PE, the formula should be written clearly; if the formula will be reused or affects multiple companies, consider consolidating it into models/, and the company page should only cite the output.

Default path, no ritual

The standard research loop is:

1. Locate: where does this question fall on the map?
2. Process: read materials, search, compare, or resolve conflicts.
3. Synthesize: distinguish facts, judgments, assumptions, and unknowns.
4. Update: update the Current Model, modules, open questions, or update log only when the model truly changes.

Do not mechanically run the full process every time. If there is no model change, state that there is no change.

Build the Map first on cold start

A cold start is not a tracer bullet. Users usually provide a sufficient amount of startup material; process the first batch of material first, establish a minimal model-map.md and the first version of the Current Model, then fill it in point by point.

A minimal map only needs to answer: research boundary, core questions, main analysis axes, and the first batch of open questions. Do not pretend that a complete judgment has already been formed.

Evidence layering

Prioritize the local dossier and user-provided material. Use external search only when the material is insufficient, outdated, conflicting, or needs verification.

Source type	Use	Risk
Primary source	Fact anchors, such as announcements, regulatory filings, raw data, interview notes	May be one-sided or outdated
Company disclosure	Company facts, products, financials, roadmap	Has narrative bias
Expert/manual notes	Experiential judgment, tacit knowledge	Verifiability is unstable
Derived material	Deep Research, NotebookLM, summaries, secondhand reports	Prone to circular references
Agent inference	Structured judgments and hypotheses	Must be labeled and cannot be treated as fact

When conflicts arise, do not force reconciliation. Record the evidence from both sides, the provisional judgment, and what evidence is needed to resolve it.

Data acquisition layer

The goal of the data acquisition layer is not to rebuild a search engine, but to convert external material into auditable evidence objects, after which the main agent judges whether to update the model.

The online public version does not require any dedicated search or local parsing tools by default. Prioritize the search, browsing, URL reading, and local file reading capabilities already available in the current agent runtime; if tools such as AnySearch, web-access, markitdown, pdf/docx/xlsx/pptx, etc. are installed, they can be used as accelerators. When these tools are unavailable, do not interrupt the work: instead use the available public search, browser, official pages, user-exported files, or ordinary file reading capabilities, and note in the Source Card the acquisition_method and limitations.

AnySearch is an optional discovery/initial screening tool: suitable for real-time search, batch search, vertical domain queries, and body extraction from known HTML URLs. When using vertical domains, first call list_domains, strictly follow the returned sub_domain, query format, and region; only for the CN domain use --zone cn. AnySearch's financial vertical results can serve as a quick snapshot of prices, market cap, valuation multiples, quotes, and financial summaries, but by default they are high-drift or vendor/aggregated data and cannot directly replace company disclosures, regulatory filings, or in-model Calculation Sheet。

When the research requires annual reports, quarterly reports, announcements, prospectuses, earnings calls, investor events, research reports, paid professional sites, podcast interviews, or terminal exports, first use references/data-acquisition-layer.md to determine the source tier, permission status, and degree of automatability. Search results, secondhand reports, research reports, and professional site content by default produce source-lead、Claim Row or open_question; only after source layering, normalization of definitions, citation anchoring, and necessary review is it permitted to form Model Patch Candidate。

Intake paid/licensed content only when the user already has authorization, a logged-in state, or a local export; do not design or execute paths that bypass paywalls, circumvent terminal permissions, or scrape sites that prohibit automation. Terminal data such as Bloomberg, FactSet, Wind, Choice, and Capital IQ defaults to API, Excel, CSV/XLS, or user export/import, with no screen scraping or crawling.

Numeric sensitivity

By default, raise source sensitivity for the following numbers:

• Non-public-feeling numbers: private company revenue, gross margin, customer count, contract value, cloud credits, purchase commitments, actual transaction prices, capacity allocation.
• Numbers with easily confused definitions: CapEx, PPE, finance lease, operating lease, uncommenced lease, purchase commitment, ARR, RPO, backlog, run-rate, GMV, MAU, DAU, token call volume.
• Model input numbers: price, utilization, throughput, power consumption, PUE, depreciation, yield, delivery cycle, unit consumption coefficient.
• Model output numbers: payback period, break-even price, demand back-calculation, supply chain gap, market space.

When recording numbers, retain at least: value, unit, point in time, source, source type, review status, and whether it is an assumption/estimate/model output. If it cannot be reviewed, do not delete it, but mark it as needs-primary-check、secondary-estimate or assumption。

Estimation standards when data is missing

When complete inputs cannot be obtained through public search or first-hand disclosure, do not simply stop, and do not throw out a high-level number. By default, continue building evidence-weighted estimate: starting from verifiable anchors, source leads, and low-level assumptions, use explicit formulas to calculate ranges or scenarios. The goal of a research model is not only to collect exact data; many key data points will never be fully public, so reasonable estimation within the boundaries of evidence is necessary.

Priority of estimation inputs:

• reported-anchor: verifiable anchors such as prior-quarter/prior-year disclosures, company announcements, financial reports, official specifications, public prices, orders, RPO, CapEx, revenue, cost, tokens, MAU, etc.
• source-lead: numerical leads from authoritative media, industry interviews, insider accounts, paid research summaries, or user materials; they may be used to constrain ranges, but source quality and freshness date must be indicated.
• derived: inputs derived by formula from reported-anchor or source-lead, such as run-rate, growth rate, unit cost, coverage ratio.
• model-assumption: low-level, explainable assumptions that can be subjected to sensitivity analysis, such as growth rate, paid rate, ARPU, unit serving cost, utilization, depreciation period, customer-backed ratio.

Permitted practices:

• Estimate current-period revenue or cost using prior-period disclosed values plus a growth-rate range.
• Estimate revenue, gross margin, or compute cost using user counts, tokens, public prices, discount ranges, and unit serving cost.
• Estimate coverage, cash pressure, and commitment quality using orders/RPO, CapEx, lease commitments, delivery cycle, and customer-backed ratio.
• Present results using base / bear / bull or low / mid / high scenarios, and indicate which parameters most affect the conclusion.

Prohibited practices:

• Directly assume market share, profit pool allocation ratio, winner weights, industry profit margin, exposure strength, or confidence level, and then treat them as calculation worksheet inputs.
• Use expert judgment, 1-5 scoring, abstract "strong/medium/weak", or subjective probability to fill hard gaps such as capacity, orders, revenue, cost, gross margin, utilization, delivery cycle, etc.
• Write source-lead or model-assumption as verified fact.

Every estimate output should be traceable to:

reported-anchor / source-lead
+ low-level model-assumption
+ formula
= derived estimate / scenario output

Only if there is not even a reported-anchor, source-lead, or explainable low-level assumption, stop at missing or 披露不足，无法计算。

Default completion criteria:

• If it can be searched, search first, and prioritize primary sources.
• When exact data cannot be found, look for the previous period's disclosure, adjacent definitions, operating metrics, management statements, credible source leads, or user materials.
• If precise values are still missing, continue with low / base / high scenarios and sensitivity.
• Only when the gap cannot be anchored to anything and no explainable low-level assumption can be constructed, stop the specific row at missing; do not let the entire model stop in the middle.
• Do not treat "incomplete data" as a reason for having no conclusion; instead output "under the current anchors and assumptions, what the conclusion is, what the most sensitive assumption is, and what evidence would overturn it."

Modeling

Common modeling objects:

• Unit economics: single GPU, single rack, single customer, single workflow, single token, or single task.
• CapEx payback: cash outlay, leasing, purchase commitments, backlog, ARR, revenue recognition, and payback period.
• Supply chain back-solving: from token / revenue / workload demand back to GPU, HBM, CoWoS, substrate, power, liquid cooling, racks, and licensing.
• Bottleneck migration: determine which link is slowest and where the bottleneck shifts after expansion.
• Sensitivity: which parameter changes would alter the conclusion, and which parameters are only second-order effects.

Model files are by default placed in models/, and are created only when there are indeed reusable formulas, parameter tables, sensitivities, or back-solving relationships. Ad hoc mental math can remain in the answer, but if it will become the basis for subsequent research, it should be captured.

When a model contains multi-step arithmetic, back-solving chains, or definition conversions, it must include Calculation Sheet or an equivalent canonical row store. Small, semantic, human-readable tables can continue to be placed in Markdown; large fact tables, repeatedly updated input rows, scenario rows, or output rows should be migrated to the dossier-internal data/, and the same CSV should be linked directly in the model Markdown, without maintaining a second complete set of tables in Markdown.

CSV is not an attachment, but the canonical rows within the dossier. Markdown remains the model specification and the human recovery entry point: it must explain what these numbers are, where they come from, why they are calculated this way, what the results mean, and where they may be misread. Do not let the model Markdown contain only row_id or CSV links.

Only add Python when calculations will be repeatedly recomputed, have cross-row dependencies, involve linked low/base/high scenarios, sensitivity ranking, Monte Carlo, or when changing one input affects multiple outputs. Python can only serve as a thin mechanical calculation layer: read input CSV, generate output CSV according to explicit formulas, and provide --check to check whether output is generated from the current input and script. Research judgments, formula explanations, and conclusion readings are still written in Markdown, not hidden in scripts.

CSV + Python maintenance rules: after input CSV or scripts change, the Agent must first recompute and run --check; then the Agent determines whether the readings / conclusions / disconfirming conditions in Markdown need to be updated. Markdown readings may be maintained manually, but it must be clear that they are model readings, not a second automatically generated output table.

CSV / Python Data Maintenance Protocol

By default, adopt the layering of "small tables in Markdown, medium structured blocks, large tables in CSV, and Python when necessary":

• Markdown tables should retain only small semantic tables, reader guides, conclusion summaries, counterevidence conditions, and a few key row references; do not use Markdown to maintain fact tables with dozens of rows or more, that are continuously updated, require sorting and filtering, or will be referenced by multiple models.
• data/markdown-tables/ Store row-level fact tables, index tables, source tables, and non-generated matrix tables migrated out of Markdown. They are still the dossier's internal data layer, not scattered attachments.
• data/calculation-rows/ Store canonical input rows. Inputs may be manually maintained, but must have stable row_id / input_key, units, source status, and explanations.
• data/calculation-outputs/ Store generated output rows. Outputs are not manually edited; to change results, first change the input CSV or script, then regenerate.
• scripts/calc_*.py Only perform deterministic calculations: read input CSV, generate output CSV according to explicit formulas, and provide --check to check whether the output was generated from the current input and script.

Whether to Pythonize should be judged by necessity, not by "if there is a table, script it":

• Should be Pythonized: cross-row formulas, low/base/high scenarios, repeated recalculation, unit conversion chains, rounding sensitivity, where changing one input affects multiple outputs, and model outputs that change the readout.
• Can use CSV only: fact tables, source indexes, company/product matrices, disclosure gaps, non-generated metric tables, and manually maintained canonical input rows.
• Should not be Pythonized:披露不足，无法计算 rows, range indexes, source-lead records, scoring/winner matrices, judgment-type readouts, and small semantic tables with no formula dependencies.

Model Markdown cannot be left with only CSV links. Every model Markdown that uses CSV/Python must retain:

• What question this model answers.
• Input definitions and unit definitions.
• Chinese formula explanation: what this number is, how it came about, and why it is calculated this way.
• Output reading: what the results explain and what they do not explain.
• Key sensitive parameters and counterevidence conditions.
• canonical input / generated output links.
• Recalculation commands and validation commands.
• Maintenance rules: after input or script changes, which readouts / conclusions require an Agent to judge whether to update them.

Migration and refactoring acceptance is performed by default:

• Back up or confirm that a recoverable point already exists; before large-scale migration, preferentially generate a dossier-level backup.
• For migrated tables, extract or script-compare the old Markdown table and the new CSV to confirm that row counts, column names, and cell contents are consistent; if there are differences, they must be categorized as: expected definition correction, updates already made after backup, Obsidian linkification, or anomaly.
• For Pythonized tables, run the generation command and --check, and compare the output with the corresponding values in the old canonical table; if the script finds drift from old manual calculations, first correct the canonical CSV, then synchronize the related readout and update-log.md。
• Run all relevant calc_*.py --check、py_compile, CSV link existence checks.
• After file migration, check whether missing old paths have been taken over by an archive or new location; do not leave unexplained missing files.

Obsidian-friendly principles:

• Link CSV directly in Markdown, so Obsidian / CSV plugins view the same canonical rows; do not copy a second complete set of tables in Markdown.
• When users need to make judgments, Markdown should provide enough process and explanation, not just list row_id.
• Tool viewing methods, plugin descriptions, and temporary operation notes must not be written into the research main text; the main text should retain only research content, data entry points, and maintenance commands.

Maintenance rules:

• A model should retain only one canonical calculation sheet / row store; other tables are readings, summaries, or visualizations.
• Derived rows must indicate the formula, and input rows must indicate the source status.
• If the same number appears in a module, Current Model, and the model, use the in-model row_id as the traceable entry point.
• If the formula, input, or script changes, first update the canonical rows / calculation script and recalculate, then have the Agent synchronize the "current results" and update-log.md。
• Do not force small judgments that have no arithmetic dependency into a table; avoid ceremony.

models/ file standard

models/ Only store reproducible models, or auxiliary files explicitly marked as non-canonical. A canonical model must start from underlying factual data, source leads, or low-level scenario assumptions, and compute outputs through explicit formulas.

Each canonical model must contain at least: model card, input table, calculation worksheet, output table, source status, limitations, and falsification conditions. The calculation worksheet must use stable row_id, and distinguish 一手已核验、derived、source-lead、model-assumption、missing、披露不足，无法计算。

It is forbidden to directly put high-level judgments, winner lists, allocation ratios, subjective scores, confidence levels, exposure strength, or industry conclusions into the calculation worksheet. Score sheets can only serve as old indexes or explanatory material, and must clearly non-canonical, and must not be current-synthesis.md、model-map.md or cited by other models as a source of calculation facts.

If capacity, orders, backlog, revenue breakdown, cost, gross margin, utilization, or lead time are missing, prioritize the "estimation standard when data is missing" to find reported-anchor, source-lead, derived, and low-level model-assumption to build scenario estimates; if these are also insufficient, the model must stop at missing or 披露不足，无法计算. Do not use expert judgment, 1-5 scoring, or high-level ratios to fill gaps.

Allowed inputs include: company disclosures, official specifications, public prices, orders/backlog, revenue/cost/profit, capacity/yield/lead time, source leads whose source status can be labeled, and low-level scenario assumptions. Allowed outputs must be traceable back to row_id and formulas.

Grill Me / Research Dialogue

grill me is not an audit, nor is it a counterargument report. It is a mechanism for dialogue with the user to advance the research model: ask about the user's priors, intuitions, experiential judgments, risk preferences, and implicit assumptions about the industry, then calibrate them together with the dossier, public evidence, and calculation models. The user's priors may be right or wrong; the approach is to label the source and status, not to directly adopt or directly reject them.

Timing to start grill:

• You have already read the current dossier or cold-start materials and can point out which analysis axis the issue falls on, rather than asking blank questions.
• The user explicitly says grill me, ask me questions, let's discuss it, help me ask my ideas out.
• Open questions are not purely public facts, but depend on the user's industry experience, investment preferences, judgment framework, or memory of the source of a certain number.
• The research model has multiple reasonable branches, and before continuing to search, it is necessary to know which mechanism the user believes more and why.
• There are numbers that feel non-public, derived estimates, or model parameters, but the key gap is "why this number is credible / what scenario it comes from / how you understood it at the time," rather than simple public verification.

Situations that do not trigger grill:

• The problem can be solved by reading local materials, running scripts, or public search.
• The materials have not been read yet, so high-leverage questions cannot be raised.
• It is only a need for audit, opposing views, source verification, or consistency checking; that should go through audit or subagent.
• The user only wants conclusions or status, and has not exposed gaps that require the user's prior input to fill.

Grill asks only 1 question at a time by default; if the user requests a round of questions, ask at most 3-5 mutually independent questions. Each question should state: the question, why it is asked, the impact model, how you can answer, and what to do if you do not know for now. After answering, the main agent is responsible for marking the content as user-prior、judgment、assumption、source-lead or open_question, then deciding whether to update the model.

Default Dossier

By default only create:

<dossier>/
  context.md
  model-map.md
  current-synthesis.md
  open-questions.md
  update-log.md
  modules/

models/、materials/、generated/, audit record directories, etc. are created on demand.team-runs/ is not a default mechanism; if a team agent in some environment is useful, it can only serve as a temporary discovery source, not a source of truth.

Structured Markdown is the source of truth.context.md is the continuation protocol and entry-point description, and does not carry research factual conclusions; factual conclusions are still based on current-synthesis.md、model-map.md, modules, open questions, and model files. Caches, indexes, search results, and agent findings cannot directly overwrite the model; they must be synthesized by the main agent before being written into core files.

Workflow entry points

• Ordinary research: if context.mdexists, read it first to restore the workspace entry point and writing rules; then read current-synthesis.md and model-map.md, locate the relevant modules, and process only the necessary materials.
• Cold start: process the startup materials given by the user, and establish the minimal context.md, map, first version of the Current Model, and open questions.
• status: do not conduct new research, only restore and report the current model state.
• modeling: when judgments depend on numbers, formulas, back-calculation, or sensitivity, establish or update a lightweight computational model.
• grill: extract the user's priors, experiential judgments, and implicit assumptions through question-and-answer, and advance open questions and model branch selection.
• major update: when a judgment is added, strengthened, weakened, or contradicted, propose a model update; if that judgment will become a subsequent basis, has weak sources, has conflicts, or affects promote, audit first.
• promote: elevate a small number of high-value results from the Research dossier to the Obsidian main knowledge base. Audit is required before promote.
• scope: when the research scope is too large, too small, or its boundaries drift, diagnose keep / split / merge / archive.
• archive: move generated artifacts, historical audits, old handoffs, and non-canonical derivative materials that should not be restored by default into archive/, which are not read by default; see the standard in references/archive.md。

For detailed processes, see:

• references/workflows.md: cold start, daily research, status, promote, scope.
• references/dossier-structure.md: file responsibilities and default skeleton.
• references/update-policy.md: update grading, conflicts, and audit triggers.
• references/agent-collaboration.md: rules for using Codex subagent.
• references/output-formats.md: output formats for status, staged research reports, updates, audits, and promote.
• references/data-acquisition-layer.md: how search, disclosure, research reports, authorized sites, and terminal imports are converted into evidence objects.
• references/source-adapter-backlog.md: priorities, MVP, and non-goals of the data acquisition toolchain.

Subagent usage

Subagent is an enhancement method, not a source of truth.

• Search-type subagent: suitable for parallel investigation of different companies, policies, competitors, papers, prices, and cases. Can use a lower-cost model. Only return findings.
• Audit-type subagent: suitable for major model updates, pre-promote checks, conflict judgments, and when the user requests an adversarial check. Must have an independent context, be read-only, and output counterpoints and evidence gaps.
• The main agent is responsible for synthesizing, adopting, or rejecting findings, and deciding whether to update the model.

Do not use Agent Teams by default. Do not let subagents concurrently edit the core dossier.

Common commands

python scripts/scaffold_dossier.py <path> --title "<topic>"
python scripts/validate_dossier.py <path>
python scripts/regenerate_index.py <path> --stdout

Scripts only perform deterministic work. Research judgment is still based on the Markdown text.

Default answer format

Keep ordinary answers lightweight:

## 定位
相关分析轴 / 模块 / 开放问题：

## 回答
已有模型结论：
新增材料或推理：
未知与证据缺口：
投资含义：

## 模型状态
no model change / minor update / major update / requires restructure
建议补丁：

For phased status use Status Brief. When completing a round of substantive research, when model judgment changes, or when the user requests a detailed report, use Stage Research Report, ensuring the user can understand the research process and conclusions without opening the md. Only expand a full update proposal when the model truly needs to be updated.