Spectronaut 设置、数据库与命令行

• 把 FASTA、GO、custom modifications 作为团队共享数据库和注释模板来管理，而不是每个项目单独维护副本。
• 任何自定义 cleavage rule 都应同步记录其设计目的，否则后续很难解释搜索空间的扩张或收缩来源。
• 如果团队同时承接标准蛋白组、PTM、免疫肽或半特异酶切项目，应在 Databases 层就拆出不同模板。
• 当项目涉及 non-canonical FASTA、开放搜索空间或复杂子库时，应同步固定数据库分组逻辑，否则 per-group precursor FDR 和蛋白层结果会失去清晰边界。

• 这一部分的顺序是 Protein Databases → Modifications → Search Engine Specific Custom Modifications → Cleavage Rules → GO Databases / Gene Ontologies → Table Import。这个顺序本身就在说明：从搜索空间到解释空间，所有基础知识库都从这一层开始。
• FASTA 导入不是一次性动作，而是 Managed FASTA 的建立过程，其中 parsing rule 会定义 accession、gene、description 等字段如何被读进 Spectronaut 并流向 report。
• Custom modifications 与 cleavage rules 共同定义搜索空间边界。把它们放在同一章，就是为了强调：修饰库和酶切规则都会直接改变 false discovery pressure。
• GO databases / gene annotations 被收在 Databases Perspective 里，说明 GO enrichment 不是后处理外挂，而是前置文件；如果这一层不统一好，后面的 GO 层就会变得残缺或不可用。
• Table Import 经常被忽略，但它是软件与团队模板、第三方格式和标准字典对接的入口，需要形成统一字段映射规范。

• 这一节先介绍 Settings Perspective 的树状结构，再引出 Save as...、Set as default 和导出到 .prop / .txt / .json。这说明 schema 被视为一等对象，而不是附属文件。
• 如果只在单个 experiment 内临时改参数，你得到的是一次性设置；如果把 schema 另存、设为默认并导出到文本格式，你得到的是团队可复用的 workflow template。
• JSON settings override 被单独提出来，是因为它允许在不破坏主模板的前提下，对项目做局部覆盖。这正是 GUI 规则向 pipeline integration 迁移时最需要的能力。
• protein inference、single-hit protein 策略和复杂数据库项目的分组边界，也应被纳入 schema 版本管理，否则同一批数据可能因为模板不同而生成不同的蛋白层交付结论。

• 高分辨 Orbitrap / TOF 数据：主搜索和精细匹配通常优先使用 ppm，因为它随 m/z 成比例缩放，更符合相对质量精度表达。
• Ion trap 或低分辨 MS/MS 数据：碎片峰宽度更接近固定 m/z 范围时，可使用 Th 或更宽的固定窗口。
• 校准搜索窗口可以比主搜索宽，用于估计或修正系统性偏移；主搜索窗口应反映校准后的实际误差分布。
• 如果报告中的 fragment mass error 或 precursor mass error 明显偏离 0，优先检查校准、仪器状态、库来源和 raw 文件匹配，而不是单纯放宽容差。

• 第一步检查校准后 precursor mass error：中位数应接近 0，P05-P95 范围越窄，说明 MS1 峰位越稳定。
• 第二步检查 fragment mass error：若碎片误差明显比前体误差更宽，应结合 MS2 分辨率、碰撞能量、谱图库来源和碎片离子类型判断。
• 第三步检查 run 间差异：如果某些 run 的误差分布单独偏移，优先排查该 run 的校准、色谱状态和 raw 文件映射，不建议用全局放宽容差掩盖问题。
• 第四步再决定窗口：校准搜索可用于发现偏移和建立校正；主搜索应使用能覆盖真实误差分布、但不过度引入干扰峰的窗口。

• General 负责 software-level defaults，其中 file name parsing schema 是自动注释的核心；这一步一旦统一，后面的 Condition Setup 能省去大量手工输入。
• Directories 负责 Search Archive、managed FASTA、libraries、results、temp 等默认路径。前面关于本地高速盘的要求，会在这一层真正落到可执行设置上。
• Plotting 会改变 review 时你看到的图像样式与边界判读逻辑，例如 expected elution time、XIC integration display 和 smoothing 相关选项，因此它直接影响人工复核的一致性。
• Reporting 则把自动输出、命名与结果保留策略统一到软件层，让 pipeline 不至于每个项目都长出不同的产物结构。

使用 Pulsar 建库时，命令从 spectronaut lg -se Pulsar 开始。后续参数定义输入 raw 文件、Search Archive、Managed FASTA、搜索 schema、library generation schema、Search Archive 输出、library 输出、实验名、protein inference FASTA 和 GO annotation。

外部搜索引擎建库从 lg -se <SearchEngineName> 开始，支持 ProteomeDiscoverer、MaxQuant、ProteinPilot、BGSGenericSearchFormat 和 Mascot。这一流程的重点是把搜索结果、对应 raw 文件、输出 library、library generation schema 和 protein inference FASTA 对齐。

spectronaut diaanalysis 用于带预编译 library 或 Search Archive 的 DIA 分析；spectronaut direct 用于 library-free directDIA。两者共享大量输入、schema、输出、FASTA、GO、condition 和 pipeline integration 参数。

示例结构：dotnet Spectronaut.dll -d "C:\data\My Experiment" -a "C:\data\My Experiment\library.txt" -s "my_settings" -o "C:\data\My Experiment\Results" -n "My Experiment 1" -f ".*\.wiff"。如果 library 自动解析失败，应先在 GUI 中加载 library 并确认必要列被正确识别，再迁移到命令行。

spectronaut combine 执行 SNE Combine pipeline。它适合从多个 .sne 文件生成统一输出，而不是把所有原始 runs 重新放进同一个超大实验里。

spectronaut manageSNE 面向已经存在的 .sne 文件。它可加载实验生成报告，也可用 --merge 在 experiment level 合并多个 SNE，生成等同于一起运行的结果。大型实验使用 --merge 可能消耗大量磁盘和内存；仅生成组合报告时优先考虑 combine。

部分选项可不带分析子命令单独执行，也可放在子命令前生效。例如 dotnet Spectronaut.dll -setTemp <path_to_temp> direct -d <raw_path> -fasta <fasta_path> -o <output_path> 会先设置临时目录，再执行 directDIA 分析。

退出码用于外部脚本判断任务状态。0 表示成功；1-9 为 activation related，例如 activation error、deactivation error、insufficient license、软件版本或 activity 不匹配；11-19 为 setup errors，例如 command-line invocation 不正确；>=20 为 later-stage errors，表示分析后续阶段发生错误。调度系统应根据这些分组决定停止、重试、报警或继续后续任务。

Windows 可直接调用 HTRMSConverter.exe -i [PATH] -o [PATH] -s [mySettings] -nogui。也可以通过 Spectronaut 的 converter 入口在 Windows 或 Linux 上调用转换任务。转换命令的参数很少，但每个参数都直接决定输入来源、输出位置、转换 schema 和是否使用 GUI。