FDRS / FCSR Classical Cube Foundations VIII

多表示同步可視化：3D、FCSR Net、Permutation、Cubie、Graph 與 Search Frontier

英文題名： Synchronized Multi-Representation Visualization: 3D, FCSR Net, Permutation, Cubie, Graph, and Search Frontier
系列： FDRS / FCSR Classical Cube Foundations
系列編號： EML-FDRS-FCSR-CUBE-08
版本： v0.1
日期： 2026-08-20
作者： Neo.K
機構： 一言諾科技有限公司（EveMissLab）
狀態： Orthodox Origin Continuation / 經典地基第八篇

摘要

FCSR 的起源優勢不是比傳統 solver 多一套搜尋演算法，而是將同一個魔方狀態以不同觀察形式同步呈現。早期 FDRS 魔方網頁原型已包含 $3D\leftrightarrow2D$ 連續 morph、permutation-based move engine、adjacency graph、連通分量、IDA* 與 FSM；然而這些功能仍以單一 Demo 為中心，尚未形成可泛化的「多表示同步語義」。

本文把可視化提升為 FDRS/FCSR 經典魔方線的一級計算層。定義 canonical puzzle state

s_k\in\mathcal S

作為唯一真實狀態，所有視圖均由 projection

R_i:\mathcal S\rightarrow\mathcal V_i

派生。對同一 move

a_k,

每個視圖的離散更新必須滿足：

R_i(T(s_k,a_k)) = \widetilde T_{i,a_k}(R_i(s_k)).

這是同步可視化的語義核心。

本文進一步區分「離散 canonical state」與「連續 animation state」。面轉動畫、 $3D\leftrightarrow2D$ morph、camera orbit 與 search replay 可以在時間參數 $\tau\in[0,1]$ 上連續插值，但只有 move commit event 才能將

s_k

更新為：

s_{k+1}=T(s_k,a_k).

因此任何 viewer 都不能自行改寫 canonical state。

在 UI 架構上，本文定義七類同步視圖：Physical 3D、FCSR Flat Net、Facelet/Permutation、Cubie、Coordinate/Invariant、Search、Proof。任一 piece、move、search node 或 certificate 被選取時，其他視圖必須透過 stable identity 進行 cross-highlighting。大量 search nodes 不直接逐點渲染，而採 aggregation、sampling、level histogram、threshold bands 與 selected-path detail，避免把「可視化所有計算」誤解成「把數百萬個節點全部畫在畫面上」。

本文亦對照現代 twisty puzzle 前端生態。cubing.js 的 TwistyPlayer 已能顯示並播放多種 puzzle 與 algorithm；KPuzzle 將 puzzle definition、pattern 與 transformation 抽象化；PuzzleGeometry 可產生 SVG、3D 幾何與 permutation 等資料。因此新版 FCSR 不應把「能畫一顆 3D 魔方」當作差異化。其新價值應放在同一 canonical state 下，幾何表示、代數表示、搜尋內部與證明狀態的同步分析。

本文最後提出 CanonicalStore + EventLog + RepresentationRegistry + SearchTrace + ProofTrace + ViewAdapters 架構，並把 deterministic replay、observer scale、cross-view selection、accessibility、performance budget 與 multi-puzzle compatibility 納入規格。這使 FCSR 從一個展平 Demo 正式提升為 Twisty Computation Observatory 的 UI 理論地基。

關鍵詞： FCSR、FDRS、multi-representation、synchronized visualization、canonical state、event log、search trace、proof trace、TwistyPlayer、KPuzzle、observer scale

1. 回到 FCSR 的原生優勢

前七篇解決了：

\text{state} + \text{algorithm} + \text{proof}.

但 FCSR 最初真正有辨識度的地方一直是：

\boxed{ \text{讓同一件事以不同觀察形式被看見}. }

2025--2026 的原型已經同時顯示：

立體魔方；
平面十字展開；
貼面 adjacency graph；
$\beta_0$ ；
solved facelet count；
solver phase；
move count。

因此第八篇不是額外補一個 UI chapter。

它是在回答：

如果 representation 本身就是 FDRS 的核心研究對象，如何保證所有 representation 真的是同一個世界的同步觀察，而不是七個各自維護狀態的 widget？

2. Canonical state：只能有一個真相來源

定義 canonical state：

s_k\in\mathcal S_{\mathrm{legal}}.

所有 viewer 都不能擁有獨立 puzzle truth。

而只能透過：

R_i: \mathcal S_{\mathrm{legal}} \rightarrow \mathcal V_i

讀取。

因此：

Canonical State
      ↓
Representation Registry
      ├─ 3D
      ├─ Flat Net
      ├─ Facelet
      ├─ Cubie
      ├─ Coordinate
      ├─ Search
      └─ Proof

UI state 可以很多個。

Puzzle state 只能一個。

3. Single Source of Truth Principle

定義：

\operatorname{Truth}(t) = s_k.

任意 viewer：

V_i(t)

都必須是：

V_i(t) = \operatorname{Render}_i(s_k,\xi_i(t)),

其中：

\xi_i(t)

只包含 viewer-local data，例如：

camera；
zoom；
selected piece；
animation progress；
panel layout；
display filter。

不得包含另一套獨立 puzzle permutation。

所以：

\boxed{ \text{view-local state} \neq \text{domain state}. }

4. Move synchronization theorem

對 move：

a_k\in A,

canonical transition：

s_{k+1} = T(s_k,a_k).

每個 representation 必須具有相容更新：

\widetilde T_{i,a_k}: \mathcal V_i \rightarrow \mathcal V_i.

且：

\boxed{ R_i(T(s_k,a_k)) = \widetilde T_{i,a_k}(R_i(s_k)). }

這個交換性就是第一篇建立的 FCSR 核心 theorem，現在被直接提升為 UI synchronization contract。

5. 離散狀態與連續動畫必須分離

魔方本體的 move 是離散的：

s_k \rightarrow s_{k+1}.

但動畫是連續的。

令 animation progress：

\tau\in[0,1].

viewer 可以顯示：

\mathcal A_i ( R_i(s_k), R_i(s_{k+1}), \tau ).

當：

0<\tau<1

時，畫面可能呈現半轉狀態。

但 canonical state 仍然是：

s_k.

只有：

\tau=1

並觸發 commit 後，store 才切換到：

s_{k+1}.

因此：

\boxed{ \text{animation interpolation is not a legal cube state transition}. }

這一點對形式驗證尤其重要。

6. Commit Event

定義：

MoveStarted
MoveProgress
MoveCommitted

真正改變 canonical state 的只有：

MoveCommitted

其語義為：

s_{k+1}=T(s_k,a_k).

MoveProgress 只改變：

\xi_i.

這可以避免：

3D 已經轉完；
Flat Net 還在舊狀態；
Search view 已經前進一格；
Proof checker 卻讀到半套 permutation；

這類同步錯誤。

7. FCSR Morph 也不是狀態轉移

原 Demo 的：

3D \leftrightarrow 2D

morph 可以寫成：

M_\lambda: \mathcal V_{3D} \rightarrow \mathcal V_{\mathrm{morph}},

其中：

\lambda\in[0,1].

當：

\lambda=0

為立體表示，

\lambda=1

為平面 net。

但對所有：

\lambda,

其底層仍應對應同一：

s_k.

因此：

\boxed{ \text{morph changes representation geometry, not puzzle state}. }

8. 七大同步視圖

本文建議新版 FCSR 第一版具有七類 view families。

V1. Physical 3D View

顯示：

cubie geometry；
stickers；
move animation；
camera；
layer selection。

V2. FCSR Flat Net

顯示：

六面平面 layout；
sticker positions；
adjacency；
cross-face strip movement；
selected pieces / patterns。

V3. Facelet / Permutation View

顯示：

54

個 facelet indices，以及 move permutation：

\sigma_a\in S_{54}.

V4. Cubie View

顯示：

(\pi_c,o_c,\pi_e,o_e).

V5. Coordinate / Invariant View

顯示：

twist；
flip；
UDSlice；
parity；
symmetry coordinate；
phase membership；
heuristic values。

V6. Search View

顯示：

frontier；
expanded nodes；
threshold；
pruning；
selected path；
phase candidates。

V7. Proof View

顯示：

legality；
solution certificate；
lower / upper bounds；
optimality status；
theorem / checker state。

9. 3D View 不再是產品核心，而是其中一個 adapter

現代 twisty puzzle 生態已經有成熟的 3D 播放器。

因此新版 FCSR 不應把：

會旋轉的漂亮魔方

當成主要研究成果。

Physical 3D 的角色是：

\boxed{ \text{human geometry adapter}. }

它與：

R_{\mathrm{flat}}, R_{\mathrm{cubie}}, R_{\mathrm{coord}}

在語義上是平行的。

這個定位反而能防止 UI 架構再次被 3D renderer 綁死。

10. Flat Net 是 FCSR 的歷史錨點

FCSR flat view 保留系列起源。

但新版功能不只：

把六面攤開。

還應顯示：

move strip transfer；
piece identity；
source / destination；
orientation；
selected cycle；
heuristic pattern；
phase constraints。

例如執行：

R

時，可以同時高亮：

右面九格；
四組側邊 facelets；
四 corners；
四 edges；
permutation cycles。

如此 Flat Net 從「展平畫面」成為：

\boxed{ \text{2D operation microscope}. }

11. Stable identity：cross-highlighting 的前提

每個實體必須有 stable ID。

例如：

corner: URF
edge: UF
facelet: U8
move: R
searchNode: N-000182
certificate: C-0041

若使用者在 3D 點：

URF corner

其他 views 應同步：

Flat Net 高亮三個對應 facelets；
Cubie View 高亮該 corner；
Permutation View 高亮其位置；
Coordinate View 顯示 orientation；
Search View 顯示 selected state 中的該 piece；
Proof View 顯示與其相關 invariant。

所以：

\boxed{ \text{selection identity must cross representations}. }

12. Cross-view selection relation

定義 entity universe：

\mathcal E.

每個 view 有：

I_i: \mathcal V_i \rightarrow 2^{\mathcal E}.

選取：

e\in\mathcal E

後，各 view 只需問：

e\in I_i(v)?

便能決定其 visual emphasis。

這比 panel 之間直接互相呼叫：

flat.highlightCell(...)
cube.highlightSticker(...)
graph.highlightNode(...)

更可擴張。

13. Move 也應是可選實體

不只 piece 可以被選。

Move：

a

本身也是 entity。

選：

R

後可同步顯示：

3D

轉哪一層。

Flat

哪些 strips 重排。

Permutation

\sigma_R.

Cubie

哪些 corners / edges 被作用。

Coordinate

各 coordinate 的 transition：

x\rightarrow x'.

Search

哪些 branch 使用：

R.

這讓「move」第一次跨視圖可觀察。

14. State Snapshot

每個 commit 後保存 immutable snapshot：

StateSnapshot
  stateId
  canonicalState
  moveFromParent
  parentStateId
  metricCost
  representationCacheRefs
  legalityStatus
  phase

UI timeline 不直接依賴 mutable live object。

因此：

s_0,s_1,\ldots,s_n

可以被任意來回 replay。

15. Event Log

所有 canonical events 進入 append-only log：

PuzzleLoaded
StateImported
MoveCommitted
ScrambleApplied
SearchStarted
SearchStopped
SolutionAccepted
CertificateVerified
ViewModeChanged

其中只有 domain-changing events 形成新 canonical state。

view-only events 不改變 puzzle truth。

16. Deterministic Replay

若初始狀態：

s_0

與 event sequence：

E=(e_1,\ldots,e_n)

固定，

replay 應得到唯一：

s_n.

即：

\operatorname{Replay}(s_0,E) = s_n.

這讓：

debug；
benchmark；
paper reproduction；
proof trace；
screen recording；

都可以重現同一次 solve。

17. Search state 與 puzzle state 不同

搜尋器同時維護大量 hypothetical states。

因此必須區分：

s_{\mathrm{live}}

與：

s_{\mathrm{search}}^{(j)}.

Live state 是目前真正顯示／操作中的 puzzle。

Search node 是 solver 假設分支中的 candidate。

點擊 search node 時，UI 應進入：

Inspect mode

而不是把 live canonical state 偷偷改成該 node。

18. Inspect Mode

定義：

s_{\mathrm{inspect}}

作為純 read-only overlay。

viewer 可以暫時渲染：

R_i(s_{\mathrm{inspect}})

但 canonical live store 仍維持：

s_{\mathrm{live}}.

退出 Inspect Mode 後回到 live state。

這對 search visualization 非常重要。

19. Search Frontier 不應逐節點全部渲染

IDA*、BFS 或 A* 可能生成：

10^5, 10^6, 10^8

級別 nodes。

「可視化所有搜尋」不能理解成：

每個 node 都畫一個圓。

這會同時失去：

性能；
可讀性；
數學意義。

所以需建立 aggregation levels。

20. Search Aggregation Levels

Level 0：Summary

顯示：

N_{\mathrm{gen}}, N_{\mathrm{exp}}, N_{\mathrm{prune}}, M_{\mathrm{peak}}.

Level 1：Depth / Threshold

顯示：

N_d

或：

N_\theta.

Level 2：Heuristic Buckets

例如：

(g,h,f)

分箱。

Level 3：Representation Classes

按：

phase coordinate；
symmetry class；
subgroup membership；

聚合。

Level 4：Selected Paths

只顯示：

current DFS path；
best path；
phase candidates；
final solution。

Level 5：Individual Nodes

只有使用者 drill-down 才顯示個別 node。

21. Observer Scale

FDRS 起源一直關心觀察尺度。

本文把 UI scale 定義成：

\omega \in \{ \text{macro}, \text{meso}, \text{micro} \}.

Macro

看：

phase；
frontier size；
solution bound；
global invariants。

Meso

看：

coordinate classes；
heuristic buckets；
patterns；
selected subtrees。

Micro

看：

某一 state；
某一 move；
某一 cubie；
某一 certificate step。

這使「觀察者尺度」成為實際 UI 操作，不只是哲學詞。

22. Same event, different observers

對同一 move：

a=R,

不同 observer 看到：

Geometry observer

\text{右層轉 }90^\circ.

Facelet observer

\sigma_R\in S_{54}.

Cubie observer

(\pi_c,o_c,\pi_e,o_e) \rightarrow (\pi'_c,o'_c,\pi'_e,o'_e).

Coordinate observer

x\rightarrow x'.

Search observer

g\rightarrow g+1, \qquad h\rightarrow h'.

Proof observer

\operatorname{Valid}(s') = \mathrm{true}.

它們不是六個事件。

它們是：

\boxed{ \text{one event, six projections}. }

23. Synchronization Frame

定義每個 committed domain event 的 frame：

SyncFrame
  eventId
  beforeStateId
  afterStateId
  move
  representations
  searchContext
  proofContext

所有 view adapters 消費同一個：

SyncFrame

而不是自行監聽別的 panel。

24. Representation Registry 與 View Adapter 分離

第三篇已提出 Representation Registry。

現在再分：

RepresentationSpec

與：

ViewAdapter

Representation 負責：

R_i(s).

ViewAdapter 負責：

\operatorname{Render}_i(R_i(s),\xi_i).

所以同一個 cubie representation 可以有：

table view；
graph view；
matrix view；

而不必重算 domain semantics。

25. Current ecosystem baseline：TwistyPlayer

截至本文日期，cubing.js 提供 TwistyPlayer，可在網頁中播放 algorithm，並支援多種 puzzle。

其 current API 已列出包括：

$2\times2\times2$ ；
$3\times3\times3$ ；
$4\times4\times4$ ；
$5\times5\times5$ ；
$6\times6\times6$ ；
$7\times7\times7$ ；
Skewb；
Pyraminx；
Megaminx；
Gigaminx；
Square-1；
Clock；
FTO；

以及其他 puzzle。

這代表「多 puzzle 3D 播放」本身已不是空白市場。

26. Current ecosystem baseline：KPuzzle

cubing.js 的 KPuzzle 把：

default pattern；
puzzle definition；
move transformation；
algorithm transformation；

放入統一 puzzle abstraction。

其 KPuzzleDefinition 包含：

name
orbits
defaultPattern
moves
derivedMoves

這和本系列第九篇要做的 generalized puzzle specification 有直接參考價值。

但 FCSR 仍需要自己的 canonical semantics / proof contracts，不能直接把第三方 runtime 當成形式證明。

27. Current ecosystem baseline：PuzzleGeometry

cubing.js 的 PuzzleGeometry 可產生：

SVG；
3D sticker geometry；
permutations；
KPuzzle definition；

等資料。

所以新版 FCSR 若需要快速支援多 puzzle，可以把這類 library 當：

\text{geometry / notation adapter}.

但我們的研究層應保持：

\text{Canonical Twisty Semantics}

與外部 renderer 解耦。

28. Current ecosystem gap：分析同步，而不只是播放

現代播放器很擅長：

顯示 puzzle；
播放 algorithm；
改 camera；
選 puzzle；
顯示 setup / scramble。

FCSR 的差異化不應跟它們比：

誰的 3D 更漂亮。

而應回答：

同一個 move 在代數、搜索、heuristic、proof 中發生了什麼？

所以產品定位應更接近：

\boxed{ \text{Twisty Computation Observatory} }

而不是：

\text{another cube player}.

29. Proof View

Proof panel 不顯示巨量 Lean source。

它顯示 claim graph。

例如：

State Legal                ✓
Move Semantics             ✓
Solution Replay            ✓
Goal Reached               ✓
Lower Bound                16
Upper Bound                18
Global Optimality          unresolved

點擊：

Lower Bound 16

才展開：

heuristic name；
abstraction；
table hash；
proof status；
theorem reference。

30. Proof status vocabulary

統一：

UNVERIFIED
CHECKED
PROVEN
CONDITIONAL
FAILED
UNKNOWN

避免用模糊的：

OK

例如：

Solution soundness    PROVEN
Global optimality     UNKNOWN
Completeness          CONDITIONAL

31. Search View 與 Proof View 必須不同

Search View 回答：

它怎麼找？

Proof View 回答：

我們憑什麼相信這個 claim？

一個 search trace 可以有：

10^6

events。

proof trace 可能只需要：

10

個 claims。

所以兩者資料模型、渲染密度與保留週期都不同。

32. Heuristic View

對 current state：

s,

顯示：

h_{\mathrm{misplaced}}(s),

h_{\mathrm{PDB1}}(s),

h_{\mathrm{PDB2}}(s),

h_{\max}(s).

使用者點某個 PDB 時，其他 panel 顯示：

哪些 pieces 被該 pattern 保留；
哪些自由度被 abstraction 忽略；
abstract index；
table value。

這使第五篇的 abstraction theorem 可以被直接看見。

33. Two-Phase View

第六篇的 boundary state：

s_1\in G_1

應成為 timeline marker。

UI 顯示：

PHASE 1
  Twist  -> 0
  Flip   -> 0
  Slice  -> 0

ENTER G1 ✓

PHASE 2
  Corner Perm
  Edge Perm
  Slice Perm

這比只把 move list 中間畫一條線更有語義。

34. Candidate Boundary Comparison

若 solver 評估多個：

b_i\in G_1,

可以顯示：

C_i = d(s_0,b_i) + \widehat d_{G_1}(b_i,e).

比較：

phase-1 cost；
phase-2 lower bound；
actual phase-2 cost；
total。

這讓「最短 phase 1 不等於最短總解」直接可視化。

35. Legality View

第二篇的 legality checker 應視覺化：

\sum o_c\bmod3,

\sum o_e\bmod2,

\operatorname{parity}(\pi_c),

\operatorname{parity}(\pi_e).

若非法：

ILLEGAL STATE
reason: single edge flip
edge orientation sum: 1 mod 2

而不是讓 solver 回：

failed

36. Color accessibility

魔方不能只靠顏色區分。

至少提供：

color；
face label；
pattern / symbol；
optional piece ID。

例如：

U / ○
R / △
F / □

這對：

color-vision deficiency；
灰階截圖；
論文圖；
AI vision benchmark；

都有幫助。

37. 動畫速度不應影響計算速度

定義：

t_{\mathrm{compute}}

與：

t_{\mathrm{display}}.

solver 可以在：

0.05\text{ s}

內完成。

UI 可以用：

5\text{ s}

播放。

兩者不得耦合。

所以：

\boxed{ \text{computation clock} \neq \text{presentation clock}. }

38. Replay Modes

至少提供：

Real-time

按原執行時間播放。

Normalized

固定每 move：

\Delta t.

Step

一次一 event。

Semantic

只停在：

threshold raise；
phase boundary；
new best solution；
proof verified；

等重要事件。

Semantic Replay 特別適合研究展示。

39. Search sampling 不能改變 proof

UI 可能只顯示：

1/1000

search nodes。

但 solver / proof layer 必須基於完整 computation。

因此：

\boxed{ \text{visual sampling} \neq \text{computational sampling}. }

除非使用者明確選擇 approximate solver。

40. Performance budgets

多 panel 同步最容易造成 UI 本身拖慢 solver。

因此建議：

renderBudgetMs
eventBatchSize
maxVisibleNodes
maxSearchTraceMemory
snapshotInterval

solver event stream 透過 batching / backpressure 送 UI。

若 UI 跟不上：

\text{drop visual frames}

而不是：

\text{drop solver events required for proof}.

41. Event priority

事件分三級：

P0：Canonical / Proof-critical

不可丟：

MoveCommitted；
GoalFound；
CertificateVerified；
PhaseBoundary。

P1：Search-semantic

可批次但應保留統計：

NodeExpanded；
NodePruned；
ThresholdRaised。

P2：Pure visual

可丟 frame：

camera interpolation；
hover；
animation frame。

這能維持 performance 與 reproducibility。

42. Worker / process boundary

未來 Web 版應把 solver 與 renderer 分開。

概念：

UI Thread
  ├─ View Adapters
  └─ Interaction

Solver Worker
  ├─ Search
  ├─ PDB lookup
  └─ Trace aggregation

Verifier Worker
  ├─ solution checker
  └─ certificate checker

原 Demo 曾因 file-origin Worker 限制等部署環境問題暴露 browser execution 邊界，因此新版一開始就應把 local-file mode 與 served mode 都納入測試矩陣。

43. Canonical serialization

每個 state snapshot 應能輸出：

puzzleSpec
state
metric
moveHistory
representationVersion

而不依賴畫面。

因此 screenshot 不是 canonical artifact。

正式可重現輸出仍是：

\boxed{ \text{UTF-8 / structured state artifact}. }

44. URL / share state

對非敏感公開 puzzle，可把：

puzzle type；
scramble；
algorithm；
selected view；

編碼到 shareable state。

但：

PDB；
search trace；
proof artifacts；

應有獨立 downloadable artifact，而不硬塞入 URL。

45. Representation provenance

每個 panel 應能回答：

你現在看的資料怎麼來的？

例如：

Cubie View
source: CanonicalCubeState v1
adapter: cubie-v1
lossless: yes

Phase1 Coordinate
source: Cubie View
adapter: phase1-kociemba-v1
lossless: no
task: enter G1

這能把第三篇的 representation metadata 直接呈現。

46. External library provenance

若使用 cubing.js：

Renderer: cubing.js
Puzzle semantics: external adapter
Canonical solver state: FCSR core
Proof status: independent

不要讓 UI 使用者誤以為：

因為畫面用了成熟 library，所以 formal solver 就被那個 library 證明了。

library provenance 與 proof provenance 必須分開。

47. Architecture

本文建議：

CanonicalStore
    ↓
EventLog
    ↓
SyncFrameBuilder
    ↓
RepresentationRegistry
    ├─ Physical3D
    ├─ FCSRFlat
    ├─ FaceletPerm
    ├─ Cubie
    ├─ Coordinate
    ├─ Search
    └─ Proof
    ↓
ViewAdapters

旁路：

SearchKernel
    ↓
SearchTrace
    ↓
SyncFrameBuilder

Verifier
    ↓
ProofTrace
    ↓
SyncFrameBuilder

48. CanonicalStore API

概念：

getState()
applyMove(move)
importState(raw)
reset()
subscribeDomainEvents()

不提供：

setStickerColorUnsafe()

給一般 UI。

手動編輯 facelets 必須走：

\text{Raw Input} \rightarrow \text{Parser} \rightarrow \text{Legality} \rightarrow \text{Commit}.

49. RepresentationRegistry API

概念：

register(spec)
encode(name, state)
describe(name)
compare(a, b)
proveOrReportCompatibility(name)

describe 應回：

injective
reversible
moveClosed
task
cardinality
proofStatus

這讓 UI 可以自動生成 representation inspector。

50. Sync correctness test

對每個合法 random state：

s,

每個 move：

a,

每個 representation：

R_i,

測試：

R_i(T(s,a)) = \widetilde T_{i,a}(R_i(s)).

這應成為 property-based test。

若 representation 已在 Lean 證明，runtime test 仍保留作 implementation regression check。

51. Replay correctness test

對 event sequence：

E,

測：

\operatorname{Replay}(s_0,E) = s_n.

並比較：

live execution；
serialized replay；
worker replay；

三者 canonical hash 一致。

52. Visual correctness 不是 mathematical correctness

即使 canonical state 正確，renderer 仍可能畫錯。

所以測試分：

Domain tests

驗：

s.

Projection tests

驗：

R_i(s).

Rendering tests

驗 visual adapter 是否正確畫出：

R_i(s).

這三層不能混為一個「看起來正常」。

53. Screenshot regression 的位置

Screenshot / pixel regression 可以檢查：

layout；
sticker placement；
selection；
panel sync。

但不能代替：

\operatorname{MoveCorrectness}.

所以：

\boxed{ \text{visual regression} \neq \text{semantic proof}. }

54. 第九篇的接口預留

第八篇不能把資料結構寫死成：

8 corners
12 edges
54 facelets

view adapters 應讀 puzzle specification。

因此：

\text{3x3}

只是第一個：

\mathcal P.

下一篇會把：

orbits；
orientations；
moves；
geometry；
goal；
notation；

全部提升為通用 puzzle spec。

55. Multi-puzzle visualization contract

對任意 puzzle：

\mathcal P,

若它提供：

\operatorname{CanonicalState}_{\mathcal P},

\operatorname{Move}_{\mathcal P},

R_i^{\mathcal P},

則同一 visualization framework 應可運作。

若某 puzzle 沒有天然 flat net：

R_{\mathrm{flat}}

可以不存在。

所以 view system 應支援：

\operatorname{OptionalRepresentation}.

56. 2D 不應被強制當 universal view

現代 cubing.js 文件也明確指出，部分 puzzle / visualization 組合目前並不支援 $2D$ 。

這提醒 FDRS：

\boxed{ \text{不是每個 puzzle 都必須被硬展平成同一種十字網格}. }

真正核心是：

\text{representation suitability}.

FCSR 起源是 flat，但 generalized FDRS viewer 不必崇拜 flat。

57. View suitability score

對 puzzle：

\mathcal P

與 representation：

R_i,

可定義：

U(R_i,\mathcal P,\tau)

其中：

\tau

為任務。

例如：

教學；
search debugging；
legality；
phase analysis；
speed playback。

同一 representation 對不同任務的 utility 不同。

這直接延續第三篇的 task sufficiency。

58. Observer profile

未來可讓使用者／AI 選：

Beginner
Speedcuber
Algorithm Researcher
Formal Verification
AI Agent

這些不是裝飾 theme。

而是決定預設顯示哪些：

R_i.

例如 Formal Verification 預設顯示：

canonical state；
certificate；
bounds；
proof dependencies。

Speedcuber 則可能預設：

3D；
alg；
move count；
timing。

59. FDRS Observer Principle

令 observer profile：

O

選擇可見 representation 集：

\mathcal R_O \subseteq \{R_1,\ldots,R_n\}.

則 observer 真正看到的是：

\operatorname{View}_O(s) = \{R_i(s):R_i\in\mathcal R_O\}.

所以：

\boxed{ \text{同一 state 的「可理解性」依 observer 的 representation set 改變}. }

這是 FDRS 起源「觀察角度」命題的可操作版本。

60. 結論