跳转到内容
Aira 3D

RFC-0013：Phase 1 Exact Shell Operation Module

项目 值
状态 Accepted
文档版本 0.4.0
创建/最后修改 2026-09-01 / 2026-09-02
Operation exact.shell@1.0.0
Module aira.op/exact.shell@1.0.0
Capability cap:model.exact.shell@1
Catalog Snapshot aira.catalog/exact.phase1@0.4.3
依赖 RFC-0006、RFC-0008、RFC-0010、RFC-0011、RFC-0012、ADR-CORE-002
Production activation false

1. 决策摘要

Section titled “1. 决策摘要”

Aira 增加独立的 Exact Shell 候选能力。AI 只表达四件事：输入实体、要移除的语义面、正厚度、向内或 向外。Core 将语义面编译为 definition-hash 与 receipt 绑定的 canonical ExactFaceSelectorSet；执行器 固定 OCCT thick-solid 安全配置并原子生成一个新的 ExactSolid。

该合同不是 BRepOffsetAPI_MakeThickSolid 的远程包装。AI 不接触 face index、Three.js object、signed offset、tolerance、join mode、intersection/self-intersection flag 或 internal-edge removal flag。语言层 只编译可审计意图，不决定几何算法是否成功；Exact kernel、history、validity 与独立 mesh 检查仍是权威。

2. 为什么下一项是 Shell

Section titled “2. 为什么下一项是 Shell”

Revolve、Fillet 与 Chamfer 已分别证明 profile feature、Edge selector 与 operation-scoped generated Face survival。Shell 复用这些基础，但增加此前尚未关闭的工业风险：

  • 一个或多个 opening Face 的稳定选择，而不是 Edge 选择；
  • inside/outside offset 的明确语义，不能借正负号猜测；
  • offset 自交、薄区坍塌、开边界生成与多 opening 相互作用；
  • source Face 的 modified/deleted history 与新 wall/offset Face 的 generated history；
  • source edit 后 opening Face 是否仍严格解析到正确实体。

因此 Shell 是检验 Aira Interface 能否从边特征扩展到面驱动实体特征的最短工业纵切面。

3. 固定 AI 合同

Section titled “3. 固定 AI 合同”

exact.shell@1.0.0 只有四个输入：

  • solid：同一 evaluation DAG 中一个有效、闭合 ExactSolid port；
  • openings：一至 32 个 canonical ExactFaceSelectorDefinition；
  • thickness：正的 canonical Length literal 或 parameter reference；
  • side：显式 literal inside | outside。

输出固定为 solid: ExactSolid / body.main。v1 不接受 signed thickness、offset tolerance、join style、 intersection、自交修复、internal-edge removal、自动选最大面或 raw kernel option。未来若扩宽语义，必须发布 新的 operation/module 版本。

3.1 Face selector primitive

Section titled “3.1 Face selector primitive”

公共 exact-face-selector/0.1 不复制各种 producer 的 Face naming schema。它绑定：

  • source body、producer node、output port 与 producer operation；
  • 已存在的 durable Face SemanticRef ID；
  • 该 SemanticRef 的 canonical definition hash；
  • exactly-one cardinality、fail-closed evolution policy 与 canonical ordering。

Core 机械生成 selector ID 与 definition hash；随后由 model.read 的 read receipt 证明它在本次 source Revision 中解析为何物。这样 Extrude、Revolve、Fillet、Chamfer 和后续导入 B-Rep 的 Face definition 都能 作为统一 Shell 输入，而不会把 producer-specific schema 塞进 Shell node。

4. 固定内核 profile

Section titled “4. 固定内核 profile”

v1 将 AI 的 side 映射为 OCCT offset 符号：outside → +thickness，inside → -thickness。执行器固定：

  • Mode = BRepOffset_Skin；
  • Intersection = false；
  • SelfInter = false；
  • Join = GeomAbs_Arc；
  • RemoveIntEdges = false；
  • tolerance 由 receipt-locked evaluator profile 提供，不进入 AMIR authoring identity。

依据 OCCT 8.0.1 官方 BRepOffsetAPI_MakeThickSolid 文档，MakeThickSolidByJoin 接收初始 solid、closing faces、offset 与 tolerance；正负 offset 决定实体外侧或内侧。官方同时说明 Intersection=true 更通用但 未完整实现且不建议使用，SelfInter 功能未实现。因此这些开关不得伪装为已经可靠的 AI 能力： BRepOffsetAPI_MakeThickSolid。

执行顺序固定为：合同与 receipt 验证 → stable sub-entity ID 反解 Face → thick-solid build → BRepCheck_Analyzer validity/closed-solid Gate → Modified/Generated/IsDeleted history 与结果拓扑成员核对 → ArtifactGraph → 独立 Exact→Mesh/Manifold Gate。任何一步失败都销毁临时 shape，Candidate、Revision 与 user head 不变。

IsDeleted 只作为原始 kernel observation 记录，不单独定义 opening 的删除语义。OCCT 8.0.1 的 BRepOffset_MakeOffset::IsDeleted 仅在实体不在结果中且 Generated、Modified 均为空时返回 true；被移除的 opening Face 可以生成封闭厚度所需的 rim wall，因此其 IsDeleted 合法地为 false。Aira 的权威删除证据固定为： selected source Face 与结果中的所有 Face 均不 IsSame，同时所有结果 Face 必须由 inherited、Modified 或 Generated history 映射，kernel IsDeleted 计数另行保留。不得把“生成了后代”误判为 opening 仍被保留。 该行为由锁定 OCCT 源码 BRepOffset_MakeOffset::IsDeleted 与真实 WASM fixture 共同证明。

5. Diagnostic 合同

Section titled “5. Diagnostic 合同”

Module 必须至少锁定：

  • SHELL_SELECTION_EMPTY / SHELL_SELECTION_DUPLICATE_FACE；
  • SHELL_SELECTION_UNRESOLVED / SHELL_SELECTION_BINDING_MISMATCH；
  • SHELL_FACE_GEOMETRY_UNSUPPORTED / SHELL_OPEN_BOUNDARY_UNSUPPORTED；
  • SHELL_THICKNESS_OUT_OF_RANGE / SHELL_THICKNESS_TOO_LARGE；
  • SHELL_OFFSET_SELF_INTERSECTION / SHELL_KERNEL_FAILED；
  • SHELL_RESULT_INVALID / SHELL_HISTORY_INCOMPLETE。

Core strict boundary 另用 EXACT_SHELL_*、EXACT_FACE_SELECTOR_* 与 SHELL_SELECTOR_*。不得自动缩小 厚度、翻转 side、丢弃 opening、改用 mesh 结果或把失败降级成 warning。

6. Candidate → Accepted Gate

Section titled “6. Candidate → Accepted Gate”
  1. TypeScript/Rust module、schema、catalog 0.4.3 与共享 corpus parity；
  2. 真实 OCCT 单 opening 与多 opening、inside 与 outside Shell 全部产生一个有效闭合 ExactSolid；
  3. 过大厚度、薄区自交、重复/缺失/stale opening 原子失败且 publication 为零；
  4. OCCT history 覆盖 inherited、结果拓扑中 absent 的 deleted opening、generated wall 与 offset Face，保留 独立 kernel IsDeleted observation，且零静默 unmapped output；
  5. 成功结果通过独立 Exact→Mesh/Manifold closed-oriented 检查；
  6. thickness edit、side edit、source edit、多 opening 与 opening delete 的 SemanticRef Survival corpus 通过， silent wrong rebind 为零；
  7. 冻结九元 Aira Interface 完成 create/edit/revert/read-back，Candidate 与 committed Revision 双证据成立；
  8. IndexedDB reopen 后 Revision、selector、receipt、ArtifactGraph 与 evidence identity 不变；
  9. Google Chrome 中 Three.js 只按稳定 Face SemanticRef/Display sub-entity 高亮，且完成 no-post、近/设计/ 远/压力视角的固定 viewport/DPR/backend 视觉验证，console error 为零；
  10. committed fresh detached checkout 使用 receipt-matching sealed runtime 离线重放全部 Gate；
  11. production capability 继续由独立 activation 变更控制，Accepted 不自动发布。

6.1 当前 Gate 状态

Section titled “6.1 当前 Gate 状态”

Gate 1–5 已由 Exact Shell kernel Candidate 收据关闭。Gate 6 现由独立 Face SemanticRef Survival 收据关闭：正向证据使用真实 OCCT history，覆盖 thickness、side、source、multi-opening 与 opening-delete 五类编辑；失败证据覆盖 stale receipt、source Face delete/split、snapshot hash 与 selector definition hash 篡改。opening-delete 被严格定义为 authoring selector set 的显式移除，不伪装成源 Face 被删除；被移除的 selector ID 必须进入 removed 集合，剩余 selector 按相同 SemanticRef ID 与 definition hash 保留，silent wrong rebind 固定为零。机器证据见 Exact Shell 验证记录；原机器报告保留在验证提交历史中。

Gate 7–9 已由共享 AMIR 0.4 Exact operation session/interface 与真实 Google Chrome 产品 Gate 关闭： interface.manifest/search/describe/read/proposePatch/preview/validate/commit/revert 九元面完成 Shell create、 2 → 3 mm thickness edit、revert 与 read-back；Candidate/Revision 双证据、权威 ValidationReceipt、CAS、 IndexedDB reload 与三笔持久化审计全部成立。receipt-matching 47-binding OCCT runtime 完成 Face selector read receipt、11 个输出 Face 的 history、Exact→Mesh/Manifold 与确定性重放；50 mm 过厚 Candidate 以 EXACT_SHELL_CANDIDATE_CONFORMANCE_FAILED 失败，task head 不变。Chrome/Three.js 只高亮 translation 产出的稳定 Display sub-entity，明确不把它冒充新的 Shell output SemanticRef；同一 Display ID 在 reload 前后不变，no-post、近/设计/远视角与 console 0 warning/error 均通过。机器证据见 Exact Shell Chrome Gate v0.1和 验证记录。

Gate 10 已在候选提交 396ff6a1ea9f6c6c52c7fd113ef9e39b84c96741 的 committed fresh detached checkout 中关闭：frozen offline install 下载为零，六套 receipt-matching runtime 全部恢复；Shell kernel 11/11、Survival 16/16、Chrome receipt、历史 Exact Edge current-conformance、完整 pnpm check 与 release tier 31/31 全部通过。全局 evidence replay 在候选提交上覆盖 45 个 verifier、165 份 report 与 814 个 workspace evidence path，missing/ignored/untracked 均为零。Accepted 收据见 Exact Shell Acceptance v0.1。

Gate 11 继续保持 production disabled；Accepted 不代表 production activation。

7. 当前裁决

Section titled “7. 当前裁决”

接受 exact.shell@1.0.0 的合同与 Gate 1–10，RFC-0013 状态升为 Accepted；不接受其作为生产能力。 production Runtime Snapshot/Session Grant、用户 head 发布、provider 与 backend 均未启用。下一能力主线回到 工业 feature catalog，每个新增 operation 仍须独立 capability/RFC、SemanticRef corpus、真实 kernel、 Chrome 产品 Gate 与 fresh-checkout 收据。