---
title: "EML-FCRPC Paper 01｜三維格子與體素位元程式表示：空間原生程式物件與裝置中立互動"
english_title: "Spatial-Native Program Objects, Voxel-Bit Representations, and Device-Neutral Interaction"
series: "EveMissLab Field-Container and Reconfigurable Physical Computing"
series_abbreviation: "EML-FCRPC"
paper: "01 / Spatial Program Representation and Interaction Contract"
version: "0.1"
date: "2026-10-22"
status: "Public-facing research draft; not yet published or submitted"
author: "Neo.K"
research_assistance: "Aletheia (AI-assisted source synthesis and drafting)"
institution: "EveMissLab／一言諾科技有限公司，台灣"
document_class: "Engineering Concept / Theoretical Interface Proposal (E/T)"
evidence_level: "E0 for this new cross-device spatial-program integration; cited DNGP software has its separate local evidence"
language: "zh-TW"
canonical_format: "UTF-8 Markdown; canonical LaTeX delimiters are $...$ and $$...$$"
license: "Undecided; requires explicit author approval before publication"
---

# EML-FCRPC Paper 01

# 三維格子與體素位元程式表示

## 空間原生程式物件、語義深度、裝置中立互動與現實投影的共同接口

**Spatial-Native Program Objects, Voxel-Bit Representations, and Device-Neutral Interaction**

> 本文是 EML-FCRPC 公開概念產品系列第二篇（Paper 01），承接《Paper 00：場容器與外部物理計算》。本文的研究對象是**可操作的程式空間表示與其控制契約**，不是已完成的現實體積投影硬體、全域邏輯計算機，亦不是已實作的光學位元處理器。

**關鍵字**：空間原生程式語言、DNGP、Genesis Matrix、三維格子、體素位元、顯示體素、語義深度、可編輯投影、動態拓樸、視圖狀態、跨裝置座標、XR、場容器、概念產品、AI 原生編輯器。

**作者：** Neo.K  
**機構：** EveMissLab／一言諾科技有限公司，台灣  
**日期：** 2026-10-22  
**版本：** 0.1  

---

## 摘要

傳統程式編輯器多以文字為主要輸入與觀察表面，雖然實際執行早已涉及依賴圖、控制流、資料流、呼叫鏈、記憶體與分散式拓樸，這些結構仍經常被不同工具局部投影為獨立畫面。三維編輯器則經常走向另一個極端：把程式節點放到具有深度感的視覺空間，卻沒有讓三維操作具有可檢查的程式語義。本文提出一個介於兩者之間的工程研究主張：**同一個 canonical 程式物件可以在桌面三維畫布、擴增／混合實境、未來真實體積投影與外部物理運算場之間維持穩定身分；人類與 AI 對可視物件的操作，只有在明確契約下才會轉譯成程式結構、部署拓樸或物理控制的變更。**

本篇延續 DNGP（Depth-Native Grid Programming）對 ProgramUnit、Relation、Interior、Projection 與 Candidate Mutation 的區分，將空間操作提升為一個**裝置中立的互動契約**。在此契約中，程式單元、空間操作格、顯示體素、編碼符號、物理運算位置與致動設備是六種不同物件；它們可以透過明確映射互相對應，但不存在預設的一對一同構關係。使用者可拖曳、旋轉、伸縮、連線、聚合及展開程式格子，卻不應因相機旋轉、畫布縮放、圖層拉開或裝置追蹤漂移而意外改寫程式依賴。

本文提出五層表示架構、四類坐標／深度、體素—位元表示型別、空間編輯命令、視覺與語義分離不變量、版本化提議—驗證—提交流程、跨裝置映射契約、有限物化與大型場景的層級載入規則，以及可以從現有 DNGP 狀態出發、而不必先造出真實體積投影機的最小測試路線。本文亦檢視 CSS 3D、glTF、OpenXR 與 WebXR 等已公開的顯示或空間座標技術，作為互動後端的參考，不將任何顯示標準錯認為新的計算語義。

**本文新增之處是跨表示、跨裝置與跨物理載體的契約提案；不是宣稱發明了三維 UI、體素資料結構、場景圖或光學資訊編碼。** 該整合提案的證據等級維持 E0，待可重現軟體與硬體實驗後另行更新。

---

## 0. 問題定位與本篇範圍

### 0.1 原始需求：把終端機的格子變成可操作三維格子

作者對 DNGP 原型的期待不只是在螢幕上排列漂亮的三維方塊。目標包含：

1. 使原本以終端機格子、文字或平面節點表達的程式結構，能以真正具有三維座標的**可操作格子**呈現。
2. 格子可自由排列、連結、聚合、縮小、放大、旋轉及視覺伸縮，適合人類觀察，也適合 AI 使用結構化接口操作。
3. 進入單一格子的內部不只是鏡頭放大，而可能對應 DNGP 的真正 computational interior；同時保留外觀放大只是純視圖操作的情況。
4. 將 Compositor 的圖層畫布、EveAtelier 的結構化視覺資產，以及 ORDR 的世界物件投影視為相關應用，但不把它們的正典資料模型混成一個程式本體。
5. 為未來在真實空間中以可見體積光點、結構光、MR 裝置或尚未成熟的體素顯示器操作程式預留接口。
6. 最長遠的路線中，程式可以被編譯為外部場容器、類比網路或可重組實體單元的配置，但**顯示動作本身不構成物理運算已執行的證明**。

這些目標並非同一個工程里程碑。本文先完成可檢查的表示契約；下一篇 Paper 02 再討論場容器的發射／致動／讀出邊界，Paper 06 則以可重構類比網路驗證配置與函數的關聯。

### 0.2 與 Paper 00 的關係

Paper 00 已將場容器分為幾何／顯示容器、物理作用容器與計算容器 [I1]。本篇的直接責任限於**第一種容器與通往後兩種的合法映射**。可見的盒子可以非常清楚地表示可用的空間，卻沒有理由僅因它被渲染出來，就獲得光學耦合、物理回授、可讀出位元與精確計算的能力。

因此有以下設計原則：

```text
表示可先於物理硬體完成。
可操作不等於可提交。
圖形相交不等於語義連結。
語義連結不等於物理耦合。
顯示體素不等於邏輯位元。
存在於 canonical store 不等於目前被載入或顯示。
```

### 0.3 本篇不處理的問題

- 不指定高功率雷射、超音波陣列、微奈米機器人或全息投影裝置的建造方式。
- 不把 DNGP 既有內部論文、私人原始碼或跨專案實驗證據自動宣布開源。
- 不要求任何一種顯示器達到真實三維自由空間體積像素的硬體標準。
- 不主張人類可以憑肉眼辨識全部高維狀態，也不把顏色、透明度直接視為無誤差的額外物理位元。
- 不宣稱三維表示天然優於文字編輯器、傳統流程圖或二維圖譜；此優勢須用實際任務測量。

---

## 1. 歷史脈絡：同一個運算結構，為何需要多種顯示方式？

### 1.1 程式語義與文字畫面的長期差異

任何大型程式往往同時具有文字序列、語法樹、控制與資料依賴、分散式節點以及狀態轉移。這些資料不可能完整地由一種排列方式同時展示。文字適合精確編輯、差異比較與版本管理；圖形適合觀察結構關係；三維可提供空間層疊、可視深度、面向與群集探索；不同顯示方式擅長不同工作。**本文不認為三維必然取代文字，而是拒絕讓單一顯示方式成為所有操作的唯一真實來源。**

DNGP 的核心提案正是「Structure is canonical; text is a projection」[I2]。其既有參考實作已建立 canonical 身分、關係、interior、版本化投影、候選式變更及有限深度的執行示例；但其 README 仍將整體定位為 Foundation／Reference MVP。本文提出的 Spatial Canvas 及未來體積投影，不能因此被描述為 DNGP 已完成的正式硬體功能。

### 1.2 從三維元素週期表到可操作程式空間

THE118 等使用 CSS 3D 變換矩陣的作品，說明即使不直接撰寫 WebGL，也能在瀏覽器裡使相同物件在表格、球形、螺旋和散點視圖間切換 [E1, E2]。這提供一個重要的**展示工程參考**：幾何位置與 UI 卡片可解耦，不同布局可由相同元素 ID 生成。

但在可操作程式空間中，僅有相同的卡片身分仍不夠。每次拖曳、連線、拆解或內部展開都可能具有不同層級的語義；必須明示哪些動作只是外觀，哪些動作形成候選程式變更，以及哪些動作可以觸及物理執行域。

### 1.3 類比電路與拓樸組合的橋梁

更長遠的目的並不是展示效果，而是讓使用者對格子與連線的操作，日後有機會映射到可重構類比網路或其他有測量契約的物理計算後端。換句話說，三維格子可先作為**設計與編譯面**；只有完成硬體映射、實際求解與讀出驗證，它才成為物理計算工作的入口。

---

## 2. 六種身分：不要讓所有「格子」混成一個物件

### 2.1 六類對象

| 代號 | 對象 | 承擔的責任 | 正典身份歸屬 |
|---|---|---|---|
| PU | Program Unit | 型別、作用域、效果、Interior、可執行關係 | 程式空間／DNGP store |
| SC | Spatial Cell | 空間操作時所見的格子、外觀與操控錨點 | 視圖文件／投影快照 |
| VB | Voxel-Bit Symbol | 離散座標及可編碼的抽象邏輯狀態 | 編碼規格或候選邏輯資料 |
| DV | Display Voxel | 特定顯示設備生成或模擬的體積畫素 | 顯示裝置、顯示影格 |
| PS | Physical Site | 介質內可尋址的作用或取樣位置 | 物理配置／後端映射 |
| AE | Actuator / Emitter | 邊界發射、控制、感測設備 | 裝置配置與校準紀錄 |

不要求一個 PU 對應一個 SC，亦不要求一個 SC 對應一顆 DV 或 PS。例如：

- 一個 Program Unit 可以在一個視圖中是立方體、在另一個視圖中是文字列，在第三個視圖中是可連接的圖節點。
- 多個 Program Units 可被折疊成一個代表群集的 Spatial Cell，而該 Spatial Cell 也可完全不對應任何實際物理單元。
- 一個顯示用立方體可能需要許多像素或體素組成；一個光學運算位置也可能需多路光束、介質、感測器與閾值判定共同形成。
- 同一個 Physical Site 可以在時間多工下處理多個邏輯任務；一個邏輯單元也可能以冗餘編碼散布在不同 Physical Sites。

### 2.2 型別分離比視覺一致更重要

在程式 API 中，PU、SC、VB、DV、PS、AE 應使用不同標籤與型別，而不是都以 `"id": 1` 的整數代替。至少需區分：

```text
program-unit:...
spatial-cell:...
voxel-symbol:...
display-voxel:...
physical-site:...
actuator:...
```

這些只是論文示意命名空間，**不是現有 DNGP 原型已採用的正式 ID 常量**。真正落地時應使用所在系統的既有 canonical ID、版本標記與 typed mapping，避免另一套 UI ID 意外取代原來源身份。

### 2.3 四種不同的「體素」語境

「Voxel」至少可在以下四個意義使用：

1. **幾何體素**：三維區域的離散化體積小單元，用來切分空間或儲存場的取樣值。
2. **可見體素**：實際顯示硬體發出、散射或重建出的可見體積元素，不一定能穩定儲存邏輯狀態。
3. **符號體素**：將某個離散格位置與抽象編碼符號綁定；它能呈現資訊，但不因此取得物理運算能力。
4. **物理計算體素（候選）**：在限定空間與時間解析度內具有可控制、可感測、可驗證物理轉換能力的作用單位；是否存在取決於介質和系統測試。

可見體素與符號體素即使位置重合，仍需透過明確映射才能認定它們指涉同一邏輯狀態。本文使用 **Voxel-Bit Representation** 描述抽象編碼及其顯示，不將每一個明亮體素宣稱為一個有效的實體位元。

### 2.4 為何不可直接計算「一個亮點有多少位元」？

若物理載體在指定雜訊、取樣與錯誤門檻下能可靠區分 $K$ 個狀態，資訊容量的上限可由可區分狀態數討論：

$$
B_{\mathrm{ideal}}=\log_2 K.
$$

但這只是理想狀態分類的容量指標，不是對某個光點實測所得的有效資訊量。若符號依賴色彩、亮度、相位、偏振或其他多參數組合，還必須估計感測噪聲、串擾、同步漂移、取樣頻寬及誤碼率。當裝置無法穩定辨識狀態時，不應因符號表宣告有 256 種顏色就宣稱已獲得八個可靠物理位元。

---

## 3. 四種空間與四種深度：最重要的反混淆規則

### 3.1 空間類型

| 空間 | 目的 | 座標可能包含 | 由誰擁有變更權 |
|---|---|---|---|
| $\mathcal{S}_{sem}$ | 程式語義空間 | ProgramUnit、Interior、Relation、作用域 | 程式 canonical store |
| $\mathcal{S}_{view}$ | 使用者工作空間 | 畫布座標、尺寸、方向、群集、鏡頭 | 使用者工作區／投影層 |
| $\mathcal{S}_{dev}$ | XR 或顯示裝置空間 | 局部、舞台、觀看者、追蹤錨點 | 裝置 runtime 與校準層 |
| $\mathcal{S}_{phys}$ | 外部物理作用空間 | 作用位置、介質邊界、感測區與時間 | 物理後端及安全控制層 |

其中 $\mathcal{S}_{sem}$ 未必有自然的歐氏三維座標。一般有向關係圖可以在三維視圖呈現，但其語義拓樸不取決於畫面投影時選用的 x、y、z。

### 3.2 深度與座標不能直接畫等號

定義：

- $d_{sem}$：ProgramUnit 的 canonical interior／語義進入深度。
- $z_{view}$：三維工作空間的視覺 Z 座標。
- $d_{mat}$：目前物化／實際載入的內部層級與細節程度。
- $z_{phys}$：某個物理裝置座標系中的位置；只有存在已校準映射時才有可比較意義。

基本規則：

$$
d_{sem}\ne z_{view},\qquad d_{mat}\ne z_{phys}.
$$

這不是說四者不能彼此關聯，而是說它們沒有默認的等價關係。例如把一個格子沿 Z 軸拉遠十公分，可能只為了看清楚它背後的連線；只要沒有下達語義變更，該格子的 interior 深度就完全不變。

### 3.3 建議的空間投影模型

令 canonical 程式空間在版本 $r$ 的快照為：

$$
\mathcal P^{(r)}=(U^{(r)},R^{(r)},I^{(r)},S^{(r)},H^{(r)}),
$$

其中 $U$ 是程式單元集合， $R$ 是關係， $I$ 是 interior／depth 結構， $S$ 是正典狀態， $H$ 是歷史／版本／來源資訊。這是**本文使用的簡化符號**，不是要取代原 DNGP 文獻的完整 ontology。

一個依賴觀察者、裝置與資源預算的視圖可表成：

$$
\pi_{m}(\mathcal P^{(r)};\sigma,\beta,\kappa)\longrightarrow V_{m}^{(r)},
$$

其中 $m$ 是呈現模式； $\sigma$ 是使用者視圖狀態與個別布局選項； $\beta$ 是載入／物化資源預算； $\kappa$ 是裝置能力與校準摘要。多個視圖可以共用 $U^{(r)}$ 的身分，卻不必共用一組視覺座標。

實際資料中應區分 `canonicalRevision`、`projectionRevision` 與 `layoutRevision`，以免使用者更改畫面布局後就被誤認為程式本體已被修改。

### 3.4 從視圖座標轉換到裝置座標

對於具有共同坐標維度的視圖點，可使用齊次座標變換：

$$
\widetilde{p}_{dev}=T_{view\rightarrow dev}(t)\widetilde{p}_{view}.
$$

在需要多級變換時：

$$
T_{view\rightarrow dev}=T_{stage\rightarrow dev}\,T_{world\rightarrow stage}\,T_{view\rightarrow world}.
$$

上式使用列向量、矩陣左乘及右側先作用的約定。工程中必須把**座標系名稱、單位、軸向、旋轉約定、矩陣儲存順序及裝置追蹤時間戳**同時寫入契約；否則即使畫面看起來正常，互相轉換時也可能產生方向顛倒、鏡射或位置漂移。

OpenXR 與 WebXR 的公開規範均採顯式 reference space 表達定位資料；它們的存在支持這樣的工程需求，但不替 EML-FCRPC 自動提供 canonical 程式或物理作用語義 [E3, E4]。

### 3.5 裝置追蹤不確定度

任何從顯示器或 XR 錨點轉換出的實體座標，都可能有定位誤差。若座標誤差共變異矩陣為 $\Sigma_p$，並在局部可線性化映射的雅可比為 $J$，可估計：

$$
\Sigma_{out}\approx J\Sigma_pJ^{\mathsf T}+\Sigma_{cal}.
$$

 $\Sigma_{cal}$ 表示新增的校準誤差模型。這只是一階近似；是否適用要依追蹤與量測系統決定。對未來實體場容器，若不確定度超過物理最小安全間距或可尋址解析度，應拒絕將視覺拖曳直接降低成致動命令，而不是默默使用最後一個座標估計值。

---

## 4. 體素位元表示：把空間、符號與時變狀態分開

### 4.1 有限離散空間

對原點 $p_0$ 及固定正向格距 $\Delta_x,\Delta_y,\Delta_z$，可先定義位置量化：

$$
q_{\Delta}(p)=\left(\left\lfloor\frac{x-x_0}{\Delta_x}\right\rfloor,\left\lfloor\frac{y-y_0}{\Delta_y}\right\rfloor,\left\lfloor\frac{z-z_0}{\Delta_z}\right\rfloor\right).
$$

結果為整數格位索引 $\mathbf i=(i,j,k)\in\mathbb Z^3$。此模型適合最初的格子渲染與拾取，但不要求每個格位都有可見物件，也不預設連續空間只能以此離散化形式表達。

如需不均勻格距、八叉樹或動態解析度，應提升為層級格位：

$$
\mathbf v=(\ell,i,j,k),
$$

其中 $\ell$ 是解析度層級，與 ProgramUnit 的 $d_{sem}$ 無關。這種編碼可協助渲染、查找與局部細節展開，但只代表呈現採樣，不代表新的數學維度。

### 4.2 Voxel-Bit 的最小語義

為避免將單個光點誤稱為計算機，建議把一個候選 Voxel-Bit 資訊物件形式化為：

$$
b=(id,\mathbf v,\mathcal A,s(t),\tau,\rho,\epsilon),
$$

其中：

- $id$：符號或邏輯物件的穩定身分；
- $\mathbf v$：格位索引，或在混合坐標系下的合法空間位置；
- $\mathcal A$：合法符號字母表與編碼表；
- $s(t)$：在時間 $t$ 的抽象狀態；
- $\tau$：狀態有效時間／演化與同步契約；
- $\rho$：顯示、感測或物理載體映射；
- $\epsilon$：容許的數值或判定誤差規格。

如果尚未配置物理介質， $\rho$ 可以只是視覺渲染綁定；若未來連接真實聲光場， $\rho$ 才能進一步包含 emitter、observable、calibration 與 physical site 的證據。**抽象 bit／符號可以存在於軟體，不需要為了取得研究合法性而假裝已有體積光硬體。**

### 4.3 單一外觀與動態資訊編碼

空間格子的形狀可以相同，卻藉由顏色、亮度、透明度、朝向、波形、圖案、尺寸、時間序列或其他通道顯示不同邏輯狀態。這適合用於展示 ISQL 等動態符號或多維編碼的概念。然而**外觀通道不是底層 canonical 字母表的全部內容**；例如色盲模式或印刷輸出無法保留某個顏色差異時，不應讓程式語義跟著改變。

建議：

```text
Canonical symbolic state
    -> Encoding profile
    -> Accessible visual glyph / voxel appearance
    -> Device sampling or human observation
```

必要時可另提供機讀標籤、形狀紋理、聲音與文字描述作為冗餘輸出，避免重要語義僅能透過色差理解。所有顯示通道必須有等價或損失聲明。

### 4.4 空間取樣與運算取樣是兩回事

渲染每秒更新 60 次，不代表實體場每秒可以獨立完成 60 次邏輯運算。若一個光學／聲光系統以其自身的調製、響應、感測及校準周期進行資料處理，則其可宣稱的有效吞吐需依完整端到端工作負載與精度量測，而不是以顯示刷新率、體素總數或雷射交叉次數直接推算。

---

## 5. 空間程式物件與動態連結

### 5.1 獨立於畫面的 ProgramUnit

對同一 canonical ProgramUnit $u$，可存在多個視覺表現：

$$
\operatorname{Cell}(u,v_1),\qquad\operatorname{Text}(u,v_2),\qquad\operatorname{GraphNode}(u,v_3).
$$

其中 $v_i$ 表示視圖實例。三個投影共享對 $u$ 的引用，但其坐標、標籤、選取狀態和 LOD 可以不同。不能用 `Cell` 在不同視圖的記憶體位址或 DOM ID 取代 $u$ 的 canonical identity。

### 5.2 邊／關係與位置是不同的量

令 ProgramUnits 為 $U$，型別關係為：

$$
R\subseteq U\times\mathcal T_R\times U.
$$

 $\mathcal T_R$ 是可驗證關係型別，例如 `depends_on`、`calls`、`reads`、`writes`、`routes_to`、`contains` 或 `derives_from`；這些與 DNGP 參考實作已規劃的關係族相容，但本文不聲稱跨裝置 UI 已能逐項提交此類關係 [I2]。

而空間佈置另為：

$$
L:U\times V\rightarrow SE(3)\times\mathbb R_{+}^{3},
$$

 $V$ 是視圖實例集合， $SE(3)$ 表示位置與旋轉剛體變換， $\mathbb R_{+}^{3}$ 表示三個軸向的正縮放。若某個 UI 允許鏡射或剪切，需另用一般仿射矩陣和負行列式／退化變換的有效性檢查；上述模型僅是非鏡射的第一版。

**變更 $L$ 預設不變更 $R$。** 這是本篇最重要、最容易測試的操作不變量。

### 5.3 格子與連線可以互相接近，但不能默默成為依賴

自由佈置可以依任務或視覺美學讓節點靠近，也可讓兩條線穿過彼此，但是否存在 `calls`、`depends_on` 或物理耦合，仍以可檢查的 relation ID 或候選部署連線為準。例如兩個格子在同一坐標重疊，並不代表產生 `contains`；兩條關係線在三維空間交叉，也不代表建立新超邊。

若 UI 有「靠近即吸附」或「插入插槽自動連線」的功能，應標明它是進入 **Semantic Edit Mode** 才允許建立候選關係，且需具有撤銷、驗證與版本衝突規則。

### 5.4 程式語義中的 Split 與畫面的切片

拖曳一個立方體的兩個可見把手，可能只是拉寬外觀；選擇真正的 `Split` 算子，則可能產生對 canonical ProgramUnit 的結構變更提案。這兩者不可只靠同一個手勢區分。建議 UI 必須可見標記操作模式、預期影響對象與可提交範圍，並保留預覽確認。

---

## 6. Spatial Canvas 命令分層：同樣手勢，四種不同後果

### 6.1 四級操作權限

| 類型 | 操作例 | 變更的對象 | 是否立即變更 canonical program？ |
|---|---|---|---|
| View Command | Pan、Orbit、Zoom、MoveViewCell、ExplodeLayers | camera／workspace／layout | 否 |
| Semantic Candidate | ConnectTypedRelation、SplitUnit、ComposeUnits、EnterInterior | canonical patch proposal／query | 否；先提議或讀取 |
| Deployment Candidate | MapLogicalUnitToPhysicalSite、ConfigureFieldBoundary | 後端映射／配置候選 | 否；必須檢查能力與校準 |
| Execute / Commit | Validate、Commit、Invoke、RunPhysicalTrial | 狀態提交或允許的執行 | 依精確權限與狀態機決定 |

特別注意 `EnterInterior` 通常是**讀取或建立新投影**，不必然修改 canonical；`Invoke` 可以造成執行效果，但又與結構 commit 不同。既有 DNGP Agent profile 原型強調觀測、提議與執行分離，本文應承襲此約束，而非把所有動作硬塞到一個 `commit` 按鈕。

### 6.2 滑鼠／手勢不直接等於程式指令

在桌面模式中，滑鼠拖曳可以改變卡片位置；在 XR 模式中，手勢選取與位姿改變也可以驅動同一條抽象命令：

```text
Device Input (mouse / touch / XR controller / hand tracking)
    -> Gesture Interpreter
    -> Explicit Command Type
    -> Authorized Command Router
    -> View Store OR Candidate Pipeline
    -> Renderer and Evidence Event
```

輸入設備可以改變，命令型別不應因設備而重新發明。手勢歧義、誤觸或追蹤丟失時，不應預設提交程式與物理配置變更。

### 6.3 編輯動作的正式規則

- **移動**：預設只改 layout pose；物理部署的座標改變需要另外送出部署候選。
- **旋轉**：預設只改畫面 orientation；不改運算依賴。
- **伸縮**：可以有 `visual_scale`、`cell_extent`、`semantic_expand` 三種互相獨立的意義，UI 要明確區分。
- **連線**：畫一條輔助線是 view overlay；建立 `depends_on` 必須形成可驗證 relation candidate。
- **分裂**：view split 只是多視窗；semantic split 才需要合法的結構計畫。
- **合併**：選取多個格子作視覺群組不等同於 canonical compose；需明示是否改作用域或 execution semantics。
- **進入**：視角穿入物件可以是 camera animation；semantic enter 必須解析真正的 interior；未知 interior 不得猜造子結構。
- **回到全域**：zoom out 可以保持所有已載入的 canonical ID，不需要把子程式重新壓成不存在的單一文本副本。

### 6.4 候選—驗證—提交協定

嚴格遵循：

```text
Gesture / AI intent
  -> Resolve target IDs and current revisions
  -> Classify (view-only / semantic / deployment / execution)
  -> Produce candidate if mutation is needed
  -> Validate type, authority, stale revisions and invariants
  -> Preview delta / possible effects
  -> Explicit accept and commit, or reject / rollback
  -> Refresh version-bound projections
```

對純視圖操作，可以直接更新私人 workspace state；對多人共用視圖，仍需要 layout version 與衝突控制。對 canonical 修改，要遵守既有 DNGP 交易模型，不可由本篇示意 API 繞過持久層的校驗。對物理裝置的控制，還需更嚴格的安全邊界與裝置許可證書，留給 Paper 02／07。

---

## 7. 遞迴格子與語義深度

### 7.1 「盒中有盒」不一定只是縮放動畫

某個 ProgramUnit 可以擁有 interior。使用者點擊「展開內部」後，可能看到該單元在獨立 ProgramSpace 中承載的其他 ProgramUnits；這不是圖形技巧，而是 DNGP 的原生可進入式程式深度 [I3]。

因此至少需要兩種不同操作：

```text
Zoom(u)   -> Camera / presentation only
Enter(u)  -> Resolve canonical interior; create new projection
```

進入運算內部時應顯示 breadcrumb、canonical path、當前 revision、可見範圍與 materialization budget。離開 interior 只會結束或改變觀察，不會刪掉被觀察的程序。

### 7.2 未知、空、隱藏與未物化不等價

| 狀態 | 意義 | 對 UI 的正確反應 |
|---|---|---|
| None / Empty | canonical 已知沒有內部 | 顯示「已知為空」，不繼續進入 |
| Unknown | 未知是否存在 interior | 顯示未知，允許查詢／待確認 |
| Hidden / Opaque | 存在但權限不允許披露 | 顯示受限占位與來源，不能直接展開 |
| Unmaterialized | 存在且可引用，但此視圖尚未載入 | 可按需擴充，保留同一 ID |
| Present | 已知有 interior，且可依條件讀取 | 建立新深度投影 |

若 UI 因效能限制暫時不顯示某個格子，不能推論該格子已從 canonical program 刪除。同理，若 AI 沒有取得某個 interior 的觀測權，不得宣稱它不存在或自動生成一個合理猜測。

### 7.3 有限物化策略

對有限視圖資源預算 $\beta=(b_U,b_R,b_D,b_T)$，其中各項分別代表最多單元數、關係數、深度和時間預算，可定義選擇性物化：

$$
M(\mathcal P^{(r)},q,\beta)\longrightarrow \mathcal P^{active}_{q,\beta}.
$$

 $q$ 是使用者當前焦點或 Agent 任務。這表示物化集合只需包含**完成本次操作必要且授權可見的區域**，不需要每次把所有內部程式、所有圖線與所有歷史一次載入。是否具備嚴格不遺漏的查詢能力，需要另定算法與驗證，不可僅依靠焦點可見性推論。

### 7.4 深度不是無限資源承諾

程式理論上可以允許持續嵌套或可生成 interior，但實際顯示與計算永遠使用有限記憶體、畫面像素、體積解析度和執行預算。本文不把無界遞迴寫成可在實體投影設備中同時顯示無限格子。UI 可以透過LOD與選擇性載入讓人理解很大的結構，卻不能繞過有限資源與可計算性限制。

---

## 8. 與 Compositor、EveAtelier、ORDR 的相容性

### 8.1 共用的是操作介面，不是本體

先前 Spatial Canvas 的設想允許 Compositor 將 Photoshop 式圖層拉成可觀察的三維平面，也允許 EveAtelier 把生成結果、遮罩、人物部件與 scene graph 分開檢查。但此處必須保留系統原有的身分與權威邊界：

```text
DNGP ProgramUnit      != EveAtelier VisualAssetGraph Node
Compositor Layer      != ORDR World Object
Image Layer Z-order   != Physical Z-distance
Canvas Manifestation  != World Canonical Truth
```

這些物件可以透過帶來源與版本的 adapter 在同一視圖中被觀察、比較與操作，卻不應把所有圖層 ID 直接寫入 DNGP 的 canonical schema。

### 8.2 圖層拉開視圖（Exploded Layer Space）

假設一份影像文件含有背景、人物與前景特效三個圖層。三維畫布可以依其合成順序讓圖層以不同的 $z_{view}$ 展開，使人類觀察者知道每層的關係。當使用者把背景往後拉時，預設改變的是 exploded view 的深度間距；回到平面合成視圖後，既有 blend、mask 與 z-order 應保持相同。

如果使用者明確切換到圖層重新排列模式，才可以提出改變文件 layer order 的候選；這項操作仍不是 ORDR 世界中物體的物理距離變更。

**反例**：同樣的圖層畫布中，僅按住 Alt 拖曳使兩層在視覺上交換前後，不可以默默改變最後輸出 PNG 的合成順序，除非模式與預覽明示並經許可。

### 8.3 EveAtelier 與結構化 2.5D 資產

EveAtelier 已有 VisualAssetGraph、Studio Canvas、圖層／遮罩與投影導出概念，且其部分 2.5D 配方明確採用**depth order only、不是實際物理公尺數**的語義。這與本文 `z_{view}` 與 `z_{phys}` 分開的規則相容。若將 2.5D 圖層映射到 3D 視圖，需保留其來源 revision 與導出損失標記；不能把某個由單張合成圖估出的 heightfield 直接當作場容器內已實測的物理深度。

### 8.4 ORDR、EveAtelierWorld 與外部場後端

ORDR 可以承擔自己版本化的世界狀態、法則與幾何；EveAtelierWorld 負責在藝術文件與持久世界之間維持明確橋接。Spatial Canvas 只能透過 bridge 顯示或送出候選操作，不取得跨系統的全域自動提交權。Paper 07 如要把這些應用接入光學或類比後端，必須保留每個系統自己的身份與 authority contract。

---

## 9. 硬體中立的空間程式中介表示草案

### 9.1 不重寫 DNGP 的語義 IR

DNGP 已設計 Semantic IR（SIR）與 Execution IR（EIR）；本文不應再造一個叫作「Canonical Program IR」的競爭性本體，也不修改原有 runtime。建議新增最薄的 **Spatial Projection Contract（SPC）**，它只持有投影與互動必要的資訊，並以 canonical ID 引用來源系統。

此 SPC 在未來可能成為硬體中立空間介面的一部分，但**不是光學／聲光／類比運算的實際執行 IR**。物理配置與回收契約留待 Paper 02、07。

### 9.2 SPC 最小物件集合

```text
SpatialProjectionSnapshot
  - sourceSystem, canonicalRevision, projectionRevision
  - visibleObjects[], relationOverlays[], occludedObjects[]
  - frameId, coordinateConvention, unitScale
  - materializationBudget, omittedCount, hiddenCount

SpatialObjectProjection
  - projectionId, sourceId, sourceKind
  - localPose, visualScale, visualAppearance
  - semanticDepth, interiorStatus, readOnlyFlags
  - permissions, provenance

SpatialRelationOverlay
  - overlayId, sourceRelationId, relationType
  - sourceObjectId, targetObjectId
  - visualPath, semanticStatus, visibleReason

SpatialInteractionCommand
  - commandId, commandType, targetProjectionId
  - expectedSourceRevision, expectedProjectionRevision
  - payload, intentClass, actor, timestamp
```

資料型別須避免把物理作用位置、裝置發射參數或感測讀數偷偷放在 `visualAppearance` 的擴充字串中。跨物理端的欄位應另外在 FieldConfiguration／Measurement 中記錄來源與證據。

### 9.3 具體 JSON 契約示例（提案；非現有服務端輸出）

下例描述一個只改變視圖位置的命令，因此其 mutation scope 指定為 `view-only`：

```json
{
  "schema": "eml-fcrpc/spatial-interaction/v0.1",
  "command_id": "cmd:demo:move-001",
  "actor": { "kind": "human", "id": "demo-user" },
  "intent_class": "view-only",
  "command_type": "MoveViewCell",
  "target": {
    "projection_id": "spatial-cell:demo:17",
    "source_id": "program-unit:demo:17",
    "source_system": "DNGP"
  },
  "expected": {
    "canonical_revision": 12,
    "projection_revision": 6,
    "layout_revision": 4
  },
  "transform": {
    "frame_id": "workspace:demo:main",
    "unit": "workspace-unit",
    "translation": [0.2, 0.0, 0.8],
    "rotation_xyzw": [0.0, 0.0, 0.0, 1.0],
    "scale_xyz": [1.0, 1.0, 1.0]
  },
  "mutates": ["layout"],
  "requires_canonical_commit": false
}
```

此命令的預期結果是布局版本更新，而 canonical revision 和原 ProgramUnit 內容、Relation 集合都不應變動。`workspace-unit` 是示例自訂單位；若需要轉為 XR／物理位置，應先做明確尺度校準，不能直接把 0.8 當成 0.8 公尺。

### 9.4 建立語義關係的候選示例（提案）

```json
{
  "schema": "eml-fcrpc/spatial-interaction/v0.1",
  "command_id": "cmd:demo:rel-002",
  "actor": { "kind": "human", "id": "demo-user" },
  "intent_class": "semantic-candidate",
  "command_type": "ConnectTypedRelation",
  "target": {
    "source_unit_id": "program-unit:demo:17",
    "target_unit_id": "program-unit:demo:23",
    "relation_type": "depends_on"
  },
  "expected": {
    "canonical_revision": 12,
    "projection_revision": 6
  },
  "effects": ["relation_candidate"],
  "requires_validation": true,
  "requires_commit_authority": true
}
```

操作 UI 可以立即畫出**候選線**，但只有經過解析、權限、型別與版本檢查，再由擁有 commit authority 的管線確認後，才可以變為正式 Relation。候選線需與已提交關係線在視覺上可區分，並能從 UI 上查看拒絕或衝突原因。

### 9.5 視圖快照和不變量示例

```json
{
  "schema": "eml-fcrpc/spatial-projection/v0.1",
  "projection_id": "view:demo:main-r6",
  "source": { "system": "DNGP", "canonical_revision": 12 },
  "layout_revision": 5,
  "coordinate_frame": {
    "frame_id": "workspace:demo:main",
    "handedness": "right",
    "up_axis": "+Y",
    "forward_axis": "-Z",
    "length_unit": "workspace-unit"
  },
  "materialization": {
    "max_units": 256,
    "max_relations": 512,
    "max_semantic_depth": 2,
    "returned_units": 2,
    "returned_relations": 0,
    "truncated": false
  },
  "objects": [
    {
      "projection_id": "spatial-cell:demo:17",
      "source_id": "program-unit:demo:17",
      "semantic_depth": 1,
      "interior_status": "unknown",
      "pose": { "translation": [0.2, 0.0, 0.8], "rotation_xyzw": [0, 0, 0, 1] },
      "visual_scale_xyz": [1, 1, 1],
      "appearance_ref": "theme:neutral"
    },
    {
      "projection_id": "spatial-cell:demo:23",
      "source_id": "program-unit:demo:23",
      "semantic_depth": 1,
      "interior_status": "none",
      "pose": { "translation": [-0.8, 0.0, 0.0], "rotation_xyzw": [0, 0, 0, 1] },
      "visual_scale_xyz": [1, 1, 1],
      "appearance_ref": "theme:neutral"
    }
  ]
}
```

這個快照的 `returned_relations: 0` 與前段 `ConnectTypedRelation` 候選完全相容：候選尚未提交，故尚未存在於已提交關係集合。`materialization` 數量是明確標示的示範資料，不是對現有 DNGP 原型的量測結果。

### 9.6 JSON 契約不能替代實際型別與驗證

上面的 JSON 只是資料交換**草案**。未來要實作需要至少建立：

- JSON Schema 或等價型別系統，限制欄位、ID 命名空間、數值範圍與版本規則。
- `translation`、`rotation_xyzw`、`visual_scale_xyz` 的長度與有限數值檢查，拒絕 NaN／Infinity、非法四元數與接近零的不可逆縮放。
- Transform 的矩陣順序與單位測試，明確處理鏡射、重疊、遮擋與深度排序。
- 後端 `source_system` 到 canonical ID 的解譯與綁定，不能僅以字串形狀合法就認為該 Unit 存在。
- 不同視圖版本的改動不可使用 last-writer-wins 默默覆寫程式語義。
- 物理設備座標不能依賴客戶端隨意寫入的浮點數，必須另有設備許可與校準界限。

---

## 10. 互動案例與可重現語義測試

### 10.1 案例 A：在三維空間排列程式格子

輸入條件：兩個已存在 ProgramUnits $u_A,u_B$，視圖版本 $v_0$，固定 canonical revision $r_0$。操作：拖曳 $u_A$ 的投影格，改變其視覺座標，再旋轉鏡頭。

期待：

```text
Before: canonicalRev=r0, relations=R0, layoutRev=l0
Action: MoveViewCell(A) + OrbitCamera
After : canonicalRev=r0, relations=R0, layoutRev=l1
```

如果 DNGP 內部的 `calls` 因拖曳而新增或消失，則視圖隔離測試 FAIL。

### 10.2 案例 B：連接兩個格子

操作：切換 Semantic Relation Mode、選兩個 ProgramUnit、指定 `depends_on`，產生候選；驗證後確認提交。

期待：候選建立前後不修改已提交關係；通過 commit 之後 canonical revision 更新，且新 relation 有自身 ID、來源、型別及端點。拖曳後的座標不應變成自動推斷的因果依賴。

### 10.3 案例 C：放大與進入的對照

對同一單元進行兩次操作：`Zoom` 與 `Enter`。Zoom 只影響視圖矩陣；Enter 需要查詢 interior 身分、授權、LOD 和深度預算。對未知 interior 應傳回 unknown，不得直接憑視覺上像一個盒子就產生虛構子程序。

### 10.4 案例 D：同一程式在三種顯示器呈現

輸入固定的 canonical revision 與相同 ProgramUnit IDs，分別輸出至：

1. 螢幕 3D 卡片／線框；
2. XR 的錨定立方體與連結；
3. 模擬的稀疏體素／體積顯示後端。

期待：源物件 ID、已提交 Relation IDs、語義深度與型別在三者間保持不變；可見的線條、亮度、細節密度與空間坐標則允許依設備能力不同。若硬體無法渲染某個符號，必須有降級或未知標記，而非默默刪掉該 ProgramUnit。

### 10.5 案例 E：圖層拉開不改 PNG 合成

選取三層圖像資產，在 Spatial Canvas 以 Exploded Layer Space 將其視覺 Z 間距拉大，再回到普通合成視圖。相同原始圖層、遮罩及透明度參數下，正常 2D 合成的像素應與操作前一致，允許由明定像素格式、色彩空間及容差產生的可解釋差異。

### 10.6 案例 F：不把模擬光場直接升格成實驗證據

使用者把三個符號體素映射到示意光場的三個位置，畫面產生動態光線交叉與顏色變化。此結果仍只是一個**視覺或數位模擬影格**；如果未建立物理介質、實際測量和結果讀出，系統證據必須維持 `simulation_only`，不得回報 `physical_trial_passed`。

---

## 11. 驗收矩陣：專門防止漂亮但錯誤的三維編輯器

### 11.1 首輪 conformance gates

| ID | 測試門檻 | 通過條件 | 失敗條件 |
|---|---|---|---|
| SPC-01 | Identity | 同一來源 ProgramUnit 在跨視圖投影仍可追至同 ID／revision | 發生 view-specific canonical ID 分裂 |
| SPC-02 | View isolation | Move／Orbit／Zoom 不修改 canonical unit、relation、interior | 畫面移動使程式執行結果改變 |
| SPC-03 | Semantic mutation | Connect／Split／Compose 先建 candidate、驗證後提交 | UI 直接繞過權限與版本寫入 |
| SPC-04 | Depth distinction | Zoom 與 Enter 有不同 API 與語義 | 展開畫面被當成新 interior |
| SPC-05 | Epistemic state | unknown、none、hidden、unmaterialized 各有合理回報 | unknown 被畫成空或消失 |
| SPC-06 | Cross-device mapping | 相同 source ID 可在不同 frame／顯示後端表達 | 座標系不明、方向或單位混亂 |
| SPC-07 | Version consistency | stale semantic candidate 被拒絕或顯式 rebase | 舊版本直接覆蓋新 canonical |
| SPC-08 | Loss accounting | 低解析顯示明示省略與降級 | 不可見物件被當成不存在 |
| SPC-09 | Physical separation | 顯示動作不能生成物理成功 receipt | 渲染成功被報為光學運算成功 |
| SPC-10 | Undo and audit | 提議、提交、拒絕、回退可追溯 | 視覺撤銷造成不可見語義殘留 |
| SPC-11 | Deterministic projection | 固定輸入／seed／版本可重建布局與基本呈現狀態 | 同條件無法追溯投影差異 |
| SPC-12 | Performance budget | 大量節點時遵守明訂 materialization budget | 場景無限載入、造成資源失控 |

這是**待執行測試規格**，不是聲稱已經跑完十二項 Gate。既有 DNGP 局部測試通過，也不可當作本篇新 UI／SPC Gate 的直接驗收結果。

### 11.2 可否證主張

**SP-H1：視圖隔離。** 在固定 canonical program 及任何允許的 view-only 操作序列下，正典圖狀態與執行語義應保持不變。若存在反例，表明此互動層違反本篇契約。

**SP-H2：跨設備語義保持。** 在固定內容及明訂的失真容忍／可見範圍下，不同顯示後端應保留相同來源物件的身分與已提交型別化關係。若設備轉換造成不可察覺的關係變更，主張不成立。

**SP-H3：可控的語義提交。** 由可視連線到 canonical Relation 的變更，必須具有候選、驗證、明確權限、來源版本與日誌；若可被任意拖曳繞過，主張不成立。

**SP-H4：三維介面的任務優勢。** 相對二維節點視圖、文字與傳統 IDE，三維表示可能改善某些深層結構探索或跨層關係定位，但也可能使空間記憶、遮擋與眼手負擔更高；若控制實驗不顯示任務改進，就應承認三維只是替代顯示方式，不能主張普遍生產力提高。

**SP-H5：物理運算分離。** 未經真實物理後端回報與獨立讀出的純 UI 原型不得產出 E3 硬體證據。若原型把視覺輸出直接歸類為硬體運算，則其證據管線不合格。

### 11.3 UX 不等於程式正確性，但兩者需要共同測試

除了 invariants，應安排標準化任務：查找跨深度依賴、比較兩種拓樸的邏輯輸出、切換程式投影、辨識未知 interior、檢查視覺更改與編譯變更是否一致。量測完成時間、錯誤率、回退次數、必要點擊／手勢、遮擋率、記憶負荷與暈動不適。使用受試者實驗時需符合適用的倫理、同意與資料保護要求；不宜用單一作者的熟練操作影片取代可比較證據。

---

## 12. 最小產品原型：可以現在製作，不必先建造奈米單元與光盒

### 12.1 MVP 的有限目標

第一個可交付軟體原型只需實現：

1. 從 DNGP 既有可讀的 ProgramUnit／Relation／Depth Projection 取得穩定 ID 與版本快照，或先使用相容的合成資料 fixtures。
2. 用現有前端能力渲染 16–128 個可操作 3D 格子，在幾個模式中切換（表格、散點、群集、螺旋等）。
3. 支援 Orbit、Pan、Zoom、MoveViewCell、Rotate、Scale、畫面群組與 View Reset。
4. 支援一個獨立的 `Semantic Connect` 候選模式，並能把候選送至合法的提議 API，而不是直接寫原庫。
5. 區分 `EnterInterior` 與 `VisualZoom`，顯示 unknown／hidden／unmaterialized。
6. 對一組固定 DNGP canonical fixture 進行 deterministic replay 與上述十二項 conformance 測試。
7. 能切換到「符號體素顯示」模式，把同一批抽象物件畫成稀疏立體格點，但不宣稱該模式是物理邏輯後端。

上述原型可在普通桌面 CPU/GPU 上完成；沒有必要一開始就以高功率雷射、實體超音波或專用 XR 頭盔作為依賴。

### 12.2 UI 實作上的可選後端

| 後端 | 適用範圍 | 注意事項 |
|---|---|---|
| CSS 3D／DOM | 小量互動卡片、編輯器原型、易保留文字與可存取性 | 大量物件與特殊透明／遮罩組合可能造成平面化或效能限制 [E2] |
| Canvas／WebGL／WebGPU | 大量實例、連線、拾取與特效 | 須另外實作文字輸入、可存取語義和命中測試 |
| glTF／3D 場景圖 | 裝置中立的部分幾何交換、轉換與層級節點 | glTF 場景節點≠ DNGP canonical ProgramUnit；需 sidecar／extension [E5] |
| OpenXR／WebXR | XR 裝置定位、輸入與空間錨定 | 需處理 device frame、時間、追蹤漂移與授權 [E3, E4] |
| 未來真實體積顯示 | 可見三維投影及可能的空間互動 | 能力、解析度、遮擋、觀測與安全均屬待評估，不能預先定案 |

如果未來出現更好的可見體素設備，只需新增 rendering adapter；**不應要求重新編碼 canonical 程式狀態**。

### 12.3 Reference adapter 示意（偽程式；非已存在 API）

```typescript
// Illustrative interface, not an existing DNGP package export.
type CanonicalRef = { system: string; id: string; revision: number };
type ViewCommand = {
  kind: 'MoveViewCell' | 'VisualZoom' | 'OrbitCamera';
  target?: CanonicalRef;
  payload: unknown;
};
type SemanticCandidate = {
  kind: 'ConnectTypedRelation' | 'SplitUnit' | 'ComposeUnits';
  expectedCanonicalRevision: number;
  payload: unknown;
};

interface SpatialProjectionAdapter {
  readProjection(query: unknown): Promise<unknown>;
  applyViewCommand(command: ViewCommand): Promise<unknown>;
  proposeSemanticChange(candidate: SemanticCandidate): Promise<unknown>;
  validateCandidate(candidateId: string): Promise<unknown>;
}
```

重點不在語言選擇 TypeScript，而是 `applyViewCommand` 與 `proposeSemanticChange` 絕對不應共用不受保護的寫入路徑。也不能讓渲染器持有通用 `commit` 能力，或把物理致動權限寫死在前端按鈕事件。

### 12.4 第一階段的失敗退出條件

如果 UI 不能保證拖曳不改 canonical、不同投影無法保持物件身份、unknown interior 被錯誤當作空、或者視圖與部署坐標無法被可靠區分，則**不應啟動物理硬體串接**。這些問題若留到真實光場或可重構電路階段，將導致更難辨認的物理安全、校準和執行正確性錯誤。

---

## 13. 從畫面中的盒子到未來的場容器

### 13.1 三個時代的相同語義來源

**第一階段：桌面三維程式畫布。** 以普通顯示器或軟體場景呈現 ProgramUnit 與 Relation，讓使用者與 AI 學會在空間中編輯、觀察、驗證同一組資料。

**第二階段：混合實境或真實可見體積投影。** 相同 canonical program 經過校準的座標轉換，呈現在使用者周圍或桌面上；光的可見化是觀察與互動介面。當顯示設備只負責渲染時，它不必承擔任何物理邏輯運算。

**第三階段：外部物理計算場／拓樸組合後端。** 程式或配置候選經過能力查詢、安全檢查及專用編譯，部署到確實具有可控制演化與讀出能力的光場、類比網路或可重組物理單元群。這個階段的硬體驗證與本篇空間 UI 完全不同，後續論文將分開處理。

三個階段可以採用相同概念上的工作空間，卻不應因 UI 連續性而冒充**物理機制的連續性**。在實現上，有些場域可能只支援純顯示，有些只支援計算而完全不可見，另有些可同時支援兩者；系統必須以 capability 明確說明。

### 13.2 影像、聲學與光學編碼要能相互替換

一段空間程式的語義必須由 canonical 物件、型別、關係與執行規則確定，而不是由單一顯示光色決定。若某裝置無法輸出要求的偏振、相位或體積刷新率，可以合法降級為不含該特徵的視圖；但若要進入真實物理運算，缺失必要控制自由度就必須拒絕部署。**視覺端允許有損呈現，計算端不能偽裝成語義等價。**

### 13.3 真正值得保存的資產

第一代原型最有長期價值的，不一定是某個 UI 動畫，而是：

- 穩定的 ProgramUnit 與 relation identity；
- 可讀可寫且明訂權限的 spatial projection contract；
- 視圖與語義變更的型別隔離；
- 版本化與可重播的互動紀錄；
- 不依賴顯示器的符號／邏輯編碼規格；
- 可供未來物理後端驗證和降級的 capability／calibration／evidence 界面。

一旦這些邊界清楚，從螢幕 3D 到 XR、從像素與圖層到稀疏體素、從軟體類比電路到某種外部場容器，就不必每次重新定義程式本體。

---

## 14. 證據、原創主張與公開邊界

### 14.1 目前的證據定位

| 項目 | 已有內容 | 本篇能否宣稱已完成？ |
|---|---|---|
| DNGP 理論與參考程式 | 既有 ProgramUnit、Depth、Relation、Projection、Agent API 研究和部分本地測試紀錄 [I2–I4] | 可表述為既有獨立工作，不等同新 SPC 驗收 |
| Spatial Canvas 視覺概念原型 | 有與 Compositor／DNGP 相關的獨立互動示意概念 | 僅代表 UI 原型，不代表正式整合通過 |
| 本篇 SPC 資料契約 | 已在本文完整提出與示例化 | E0；尚未宣稱實作、驗收或標準化 |
| 真實 3D 體素投影 | 本系列的遠期硬體研究目標 | 尚未完成 |
| 光學邏輯／類比場計算 | 有各自文獻和其他系統先例 [I1] | 本系列未完成新的物理測試 |
| DNGP 編譯到真實場容器 | 預定 Paper 02／07 發展 | 尚未完成 |

### 14.2 本篇可合理主張的新研究內容

本篇提出以下跨領域工程約束之組合：

1. 六類物件身份及其型別化映射，避免 UI、符號與物理端混淆。
2. 將語義空間、視圖空間、裝置空間與物理作用空間獨立建模。
3. 把自由 3D 拖動、連線、伸縮與語義 interior 進入分成可檢查操作。
4. 用版本化候選流程控制從 Spatial Canvas 到程式關係圖的修改。
5. 保留 XR／真實體積顯示與光學計算之間的清楚分界。
6. 建立不依賴專門硬體、可從 DNGP 參考原型開始的 conformance 與 UX 實驗規格。

這些是可提出、可測試的系統設計候選，不等於任何一項技術世界首創或已通過效能實驗。

### 14.3 與既有成果的優先區分

- 顯示座標轉換、場景圖與 3D transforms 有既有標準，不應寫成新數學定理 [E2–E5]。
- DNGP 是先前研究，不應把它改名為本篇新發明。
- `Voxel-Bit` 在本篇只是一個暫定資訊編碼名稱，不指已標準化的物理位元。
- DNGP、ISQL、Compositor、EveAtelier、ORDR 的詳細內部機制、私人程式碼及未公開資料應在作者明示授權前保留於原儲存庫，不因本篇公開發表而自動附出。
- 本篇沒有設定全域光學計算機、奈米 AI 群集的已完成時程、吞吐倍率或商用價格。

---

## 15. 結論與下一篇接口

空間原生程式介面的要點，不是先把文字替換成三維方塊，而是使使用者與 AI 可以在三維環境裡對**同一組穩定程式身分、型別化關係、可進入 interior 及版本化觀察**進行操作，同時不讓顯示細節和追蹤噪聲改變 canonical 程式本體。這也是本文把 ProgramUnit、Spatial Cell、Voxel-Bit Symbol、Display Voxel、Physical Site 與 Actuator／Emitter 分成不同類型的原因。

對現階段而言，三維格子、拖曳、連線和多視圖呈現可以在一般桌面運算設備上實作；對遠期而言，真正的體積投影、外部光學／聲光運算及可重組實體資訊單元將各自面臨完全不同的物理驗證門檻。唯一值得先建立並長期保留的共同資產，是跨裝置與跨介質時仍可檢查、可回退、可追溯的**程式—視圖—物理配置界面**。

**Paper 01 建立的是可檢查的表示契約及研究計畫，不是已驗收的空間程式編譯器，也不是已完成的物理體素計算原型。**

下一篇 Paper 02 將把「外部的外部」正式建模為邊界發射、致動、感測與控制界面，進一步討論聲學、光學及其他物理載體可受控運算的最小條件。

---

## 參考資料

### 作者既有研究與本系列前篇

- **[I1]** Neo.K（2026）。《EML-FCRPC Paper 00：場容器與外部物理計算》，v0.1，2026-10-22。與本文同一公開草稿系列；場容器及物理運算的邊界與證據規則。
- **[I2]** Neo.K × Aletheia（2026）。《DNGP Paper 00：從平面程式碼到深度原生格子程式空間》；《DNGP Paper 01：Program Unit Ontology》；《DNGP Paper 12：Genesis Matrix / Agent-Native Programming Interface》，2026-09-23，既有研究原稿，公開引用前須依作者決定開放範圍。
- **[I3]** Neo.K × Aletheia（2026）。《DNGP Paper 02：Depth Semantics》，2026-09-23。區分 semantic depth、runtime depth 與 display depth；本文保留「語義深度不是視覺 Z 軸」的核心界線。
- **[I4]** Neo.K × Aletheia（2026）。《DNGP Paper 10：Projection and Materialization》及參考原型 `src/dngp/runtime/projection.py`；只引用抽象設計與版本／權限規則，不複製私有程式碼。
- **[I5]** Neo.K（2026）。《AetherGlass–LaserCPU v2.0》及《TCE v2.0》公開修訂版，2026-07-30。光電物理後端與拓樸執行控制；不同於視圖表示層。
- **[I6]** Neo.K × Aletheia（2026）。《GCCFT Paper 00：全域耦合計算場論的形式核心》，2026-09-22。耦合與動態拓樸為計算形式；不等於顯示幾何必然是計算。

### 外部技術與標準參考（2026-10-22 檢視）

- **[E1]** emmakyitt. *the118-pTable*, GitHub repository. https://github.com/emmakyitt/the118-pTable 。3D CSS 變換與多布局視覺示範，並非程式語義規格。
- **[E2]** W3C CSS Working Group. *CSS Transforms Module Level 2*, Working Draft, 2021-11-09. https://www.w3.org/TR/css-transforms-2/ 。3D transforms、`preserve-3d`、flattening／grouping property 的可檢查規則。
- **[E3]** Khronos Group. *OpenXR Specification 1.1*, Section 7, Spaces. https://registry.khronos.org/OpenXR/specs/1.1-khr/html/xrspec.html 。XR reference spaces 與位置定位契約。
- **[E4]** W3C Immersive Web Working Group. *WebXR Device API*, Section 6, Spaces. https://www.w3.org/TR/webxr/ 。XRSpace、XRReferenceSpace 與每一 frame 的坐標解釋。
- **[E5]** Khronos Group. *glTF 2.0 Specification*, Nodes and Transformations. https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html 。3D 場景圖的節點與局部變換參考，不是程式 canonical store。

---

## 附錄 A：術語字典

| 術語 | 本篇的精確含義 |
|---|---|
| Spatial-Native Program | 對程式本體具有穩定身份及可編輯結構的空間表示計畫 |
| ProgramUnit | 由原程式空間定義、可被追蹤並驗證的程式物件 |
| Spatial Cell | 可被人類／AI 在工作空間中操控的視覺投影單元 |
| Voxel-Bit Symbol | 具有抽象編碼與坐標的符號資料，不預設物理運算能力 |
| Display Voxel | 真實或模擬顯示裝置中的可見體積畫素 |
| Physical Site | 實體運算介質中的受控或可觀測位置 |
| Semantic Depth | 可進入的程式 interior 結構層級，不是 Z 軸 |
| Materialization Depth | 這一次視圖或任務真正載入的深度與細節 |
| Exploded Layer Space | 將平面圖層沿視覺 Z 軸分離以便檢查的視圖 |
| Spatial Projection Contract | 將程式／資產／世界物件映射到可操作三維視圖的候選契約 |
| Semantic Candidate | 尚未通過驗證與提交的結構變更提議 |
| Field Container | 由有限邊界、介質、致動、狀態與讀出共同約束的外部物理計算域 |

## 附錄 B：常見失敗模式

1. 把 `z_view` 當作 `semantic_depth`，拖曳物件就誤改 nested interior。
2. 把兩個 visually touching cells 當作具有 `calls` 或 `depends_on` 關係。
3. 把畫布截圖當作下一輪的 canonical source，造成 identity 與型別遺失。
4. 把 `hidden` 視為 `absent`，使 AI 推斷不存在的正典狀態。
5. 把 `unknown interior` 自動補成想像的子程序。
6. 把裝置追蹤漂移寫回 canonical 程式坐標。
7. 把 CSS 3D 渲染成功當作場容器物理運算通過。
8. 把圖層拉開的視覺次序當作 Photoshop 式合成的實際 z-order。
9. 把高維顏色編碼的理論狀態數當作實測可用位元數。
10. 把舊版本 Candidate 在另一人提交之後直接覆寫成最新語義。

## 附錄 C：可重現研究紀錄模板

```text
Experiment ID:
Research claim / gate ID:
Canonical source and revision:
Projected objects and source IDs:
Projection type / layout revision:
Rendering backend and version:
Coordinate frames, units and handedness:
Input device and interaction mode:
Semantic command or view-only command:
Expected effects and authority:
Observed source/unit/relation diff:
LOD, omitted and hidden counts:
Performance / precision / drift:
Reproduction seed and test fixture:
Validator and result receipt:
Failure explanation or unresolved uncertainty:
Evidence tier:
```

## 附錄 D：對外發布前確認

本文是可供閱讀與外部審稿準備的完整 Markdown 草稿，**尚未提交、刊登、上傳或核定授權**。對外釋出前由作者確認：標題與縮寫、署名／AI 協作揭露、正文授權、附帶程式碼授權、DNGP 等既有私有研究的可披露範圍、文字與畫面截圖的權利狀態，以及公開後可能影響的專利／智慧財產策略。所有正式數學原稿均以本 UTF-8 Markdown 檔為唯一 canonical source，不依賴聊天畫面的數學渲染重新拼接。