可行性分析

用户只问“能不能申报”、某一项硬门槛、单个差距或一条政策条件时，只核验并回答该问题，不自动生成完整门槛矩阵、评分映射、行动清单或报告文件。以下完整流程只在用户明确要求前期评估、可行性分析、报告或完整项目判断时执行。

强制执行顺序

1. 企业名称加项目名和报告意图即可启动，现有资料可同时提供但不是启动前提，不要求用户重复填写企业基本信息。先以企业名称作为主体检索键，按 企业数据源有限降级协议 补齐统一社会信用代码、现名、曾用名、登记地区和主体状态；无法核验的字段在报告中明确标为待核验，不因缺少单独的“企业基本信息表”拒绝出具前期评估或可行性分析。“双报告”以及“专精的前期报告和中期分析”等受控别名，只映射为“项目前期评估报告”和“项目申报可行性分析报告”两份交付；不新增“中期报告”第三种报告。分别以 preassessment 和 feasibility 运行受控模板选择。仅解释、摘录或普通改写已有报告时，不得重新生成两类报告或创建新文件。项目全称、地区、申报年度、批次以及新申报或复核类型从用户资料和政策原文中提取；任一信息可能改变适用规则时，先调用 policy-retrieval 取得管理办法、工作指引和当期通知。任务属于前期评估或培育规划时，同时读取 references/policy-application-path-contract.md，不得只给资格判断而省略项目的建设和申报路径。用户要求“项目前期评估报告”或“项目申报可行性分析报告”时，还必须完整读取 references/two-report-contract.md 和 references/report-template-registry.json，并与对应项目领域技能组合执行。高企、专精特新中小企业、小巨人、三首、研发中心、制造精品、单项冠军、绿色工厂、数字化及科技计划类命中受控模板时，必须先运行 python3 scripts/select_report_template.py --project-type <项目> --report-type <preassessment|feasibility> --output-dir <交付目录> --enterprise <企业>，基于复制出的可编辑 Word 母版回填；不得脱离模板重新排版。进行自动化成稿时，可将客户资料、原文锚点和项目事实写入技能树之外的私有夹具，再运行 python3 scripts/fill_report_template.py --template <已复制母版> --output <成稿.docx> --fixture <私有夹具.json> --report-type <preassessment|feasibility> --release-tag <版本> --public-root <公共源码根目录>。自动成稿必须命中真实原文锚点，且不得将客户原件、绝对路径或客户成稿放入公共候选包。夹具中的公开来源必须显式提供官方链接；本地文件来源只提供文件名和原文锚点，不得把内部校验值、绝对路径、候选验收标记或培训版本字样写入对外交付。未取得原文时才按统一报告骨架生成，且不得冒充已使用受控模板。
2. 读取 references/feasibility-decision-model.md，建立规则台账。每条规则标明规则类型、原文、来源、适用范围、时间状态和是否一票否决；不得把历史政策或同类项目规则拼入当期规则。
3. 读取 references/evidence-state-model.md，将企业事实逐项映射为“verified、computed、claimed、missing、conflicting、not-applicable”。只有 verified 和复算通过的 computed 可以直接支撑硬门槛。
4. 先判断排除项和硬门槛，再处理评分项。硬门槛出现 failed 时结论为不可申报；出现 missing、conflicting 或关键 claimed 时不得给出确定达标结论。
5. 财务门槛先查找 artifacts/enterprise-financial-facts.v1.json 或同契约文件，调用 financial-verification 核验企业、期间、单位、币种、合并范围和证据。按 references/calculation-review-rules.md 展示公式、原始值、单位、结果和复核状态。
6. 将评分细则逐项映射到事实，不以企业入选案例反推评分，不把同一证据重复计入互斥评分项，不将可能得分计入确定得分。政策未公布评分细则时只分析条件和竞争力，不虚构分值。
7. 按 references/conclusion-contract.md 生成结论、依据、风险和行动。先给三档结论，再给逐项依据；不承诺获批。

结论规则

• 可申报：所有硬门槛均为 passed，不存在一票否决，关键证据已核验；评分项如有，只将确定分计入。
• 有条件申报：未发现明确硬门槛失败，但存在可在申报前补齐的关键证据、口径冲突或待确认规则。
• 不可申报：任一适用硬门槛明确失败，或命中当期政策的一票否决项。
• 暂无法判断：项目版本、政策原文、企业主体或关键数据不足，无法安全落入前三档。此状态不是“有条件申报”。

停止与降级

• 同时命中多个政策版本、缺少当期官方通知或政策时效清单标为 stale 时，停止形成正式资格结论，先补政策。
• 财务事实属于其他主体、期间不足、口径不一致或质量为 unverified 时，停止复用并列出补证要求。
• 只获得企业自述、媒体报道或历史入选名单时，将其作为线索，不升级为硬门槛事实。
• 税务、司法或舆情风险只有在当期政策明确规定为排除项时才转化为资格判断。

交付与自检

输出固定包含：项目版本、总体结论、硬门槛矩阵、评分映射、计算复核、证据缺口、不确定性、风险和按截止时间倒排的行动清单。两类报告按双报告合同分别控制深度：前期评估只呈现决定谈单判断的核心条件、现有数据和补强动作；可行性分析在取得现行评分表时完整拆分评分项。前期评估另须按政策路径合同写清主管部门、政策状态、当前起点、先行建设、梯度依赖、建议年度、典型流程、材料证据、停项条件和责任动作；即使当前不可申报或优先级较低也不得省略。形成结构化结果时运行：

python3 scripts/validate_feasibility_assessment.py <结果.json>

校验失败时不得交付确定性结论。

生成两类正式报告时，应分别运行报告画像校验，并显式传入技能包根目录：

python3 scripts/validate_report_profile_delivery.py --package-root <技能包根目录> --state-root <当前企业空间/.enterprise-project-assistant/report-validation> --profile-id <project-presale-assessment-report|project-feasibility-analysis-report> --artifact <报告.docx> --artifact <报告.pdf>

画像校验会按本轮实际交付格式核对必备章节、必备表格、可打开性、中文字体和配置的页眉水印；默认只校验 Word，用户明确要求 PDF 时才追加 PDF 校验。实际内容或版式不合格时先修复再交付；内部状态目录或回执写入不可用时如实说明，不得把内部回执编号、校验值或本机路径写入对外交付，也不得据此拒绝用户继续修改已经生成的文件。

受控 Word 母版只固定结构、表格、项目专属核心对象、补强入口和可配置页眉水印，不固化政策数值。回填时仍须用当期通知原文替换占位项；母版中的条件只是待核验结构，不得当作现行政策证据。默认只交付并校验一份可编辑 Word；只有用户明确要求 PDF 时，才从同一份已定稿正文导出 PDF 并追加 PDF 验收，不得重新生成正文或默认同时交付两种格式。

对外报告的数据来源附录只保留“序号、文件名称、链接”三列。官方网页使用可点击原文链接；本地或用户提供文件的链接列写“本地文件”。文件哈希、读取回执、命中锚点和本机路径只保存在内部校验回执中，不得出现在 Word、PDF、对话正文或文件卡片说明里。

案例包可用于比较材料结构、指标分布和证据类型，但不得把案例值当成政策阈值或当前企业事实。可行性结论仍以当期政策和当前企业证据为准。