Case intake
APP PRODUCT案件委托与原始资料
创建案件 ID，提交委托书、文件与文件夹，并保留客户原始目录层级。
AUDITOUTLINE / PAPERS / REPORTS
把杂乱的案件材料，编译成可追溯、可复核的专业报告。
AUDIT 从委托书和原始目录开始，先形成案件策略，再把票据、合同、招投标和司法材料组织为证据库，最后经过穿透核验、起草与复核形成交付报告。
生产链
业务真值逐步形成。
每一步都产生下游可以消费的业务 Product。nexrur 执行这些合同，但不会替 App 定义阶段结论。
- Overview / OutlineAPP PRODUCT
策略与交付结构
形成策略、核心事实、核心主体、交付目录和证据目录五类可读产物。
- Vault / PapersAPP PRODUCT
证据结构化
提取、分类和清洗发票、合同、招投标与司法材料，保留来源和稳定引用。
- ReportsAPP PRODUCT
穿透核验与报告生产
组合 penetration、QCC、drafting、finalize 与 review，形成可校验报告生产包。
- DeliveryAPP PRODUCT
确认、归档与交付
客户确认后进入最终交付；可见性、生成门禁和运行状态保持三条独立真相。
所有权账本
业务主权与运行机制分开。
App 回答“什么是正确的业务结果”；nexrur 回答“这条程序如何可靠执行、解释失败并恢复”。
- 审计业务语义、委托约定与交付语言
- 证据充分性、主体关系和专业判断
- Outline / Papers / Reports 的 production semantics
- 报告结构、结论、可见性与交付规则
- 执行 outline → papers → reports 合同图
- Evidence / Digest / Obligations 五桶组装
- Schema facts、Step6 evidence 与 projection
- Diagnosis、Campaign、restart 与 checkpoint
五桶证据
上下文不是一锅日志。
运行时只装配当前阶段需要的有界证据。五桶说明材料从哪里来，不替材料做业务裁决。
payload、artifact refs 与 schema contracts
案件 phase、checkpoint 与 schema facts
审计 prompts、module contracts 与上游产物
按案件与主体检索的可追溯上下文
已审核审计模式、反例与报告结构
从失败到恢复
失败不被包装成成功。
下面是说明职责边界的概念路径，不是一次真实运行结果，也不是写入底座的 App 默认 route。
- 01 / PRODUCT SIGNAL业务事实暴露问题
关键合同、票据或主体证据不完整，导致 Papers 或 Reports 无法形成可消费 Product。
- 02 / DIAGNOSIS证据化解释
Diagnosis 分离原始 Product reason 与解释结果，指出证据缺口及被排除的原因。
- 03 / CAMPAIGN受合同约束的控制
Campaign 只消费 AUDIT 合同允许的 route，不由 Schema 或报告脚本私自跳转。
- 04 / NEW CYCLE回到合法执行范围
回到合法的 outline、papers 或 module scope 补证重做；已有有效产物和稳定引用继续保留。
REFERENCE PROGRAM / AUDIT
进入 AUDIT 应用 ↗查看业务应用，理解底座如何被真正消费。
本页解释架构关系；真实产品体验与业务语义由对应应用站拥有。
SOURCE BASISAUDIT/.gemini/skills/DESIGN.md · AUDIT/.gemini/skills/DESIGN_SUBAGENT.md · audit-web/DESIGN_AUDIT.md