FDRS / FCSR Classical Cube Foundations IX

從 $2\times2\times2$ 到多面體：Twisty Puzzle 的通用規格層

英文題名： From $2\times2\times2$ to Polyhedra: A General Specification Layer for Twisty Puzzles
系列： FDRS / FCSR Classical Cube Foundations
系列編號： EML-FDRS-FCSR-CUBE-09
版本： v0.1
日期： 2026-08-20
作者： Neo.K
機構： 一言諾科技有限公司（EveMissLab）
狀態： Orthodox Origin Continuation / 經典地基第九篇

摘要

前八篇已經把標準 $3\times3\times3$ 魔方拆成合法狀態、表示、搜尋、heuristic、Two-Phase、形式驗證與同步可視化。若系統仍把 $8$ 個 corners、 $12$ 個 edges、 $54$ 個 facelets、六個 face turns 與十字形 flat net 寫死在程式中，則它仍然只是「一個做得比較完整的 3x3 solver」，而不是可延伸至 twisty puzzle 領域的基礎設施。

本文提出通用 TwistyPuzzleSpec。核心不再以「立方體」為中心，而以 piece orbit、位置、orientation modulus、move transformation、合法動作判定、goal、metric、notation 與 optional geometry 為中心。對一個 puzzle，令 orbit 集為

\mathcal O=\{O_1,\ldots,O_r\}.

每個 orbit $O_i$ 有

n_i

個位置與 orientation modulus

m_i\geq1.

在沒有額外合法性限制的 raw orbit model 中，該 orbit 的狀態可表示為

S_{n_i}\ltimes\mathbb Z_{m_i}^{n_i},

其中 permutation 描述 pieces 的位置，而 orientation vector 描述每個 piece 的局部朝向。整個 raw state space 是各 orbits 的乘積；真正 legal state space 則不以人工列舉所有 parity / orientation constraints 為必要定義，而直接定義為 solved pattern 在合法 move transformations 生成之系統中的 reachable component。

本文同時區分兩類 classical twisty systems。第一類是 total reversible move systems：每個基本 move 在每個合法 state 上皆定義，典型 group-action puzzle 可以直接以有限生成群描述。第二類是 fixed-rule constrained systems：規則本身不變，但某些 move 是否可執行取決於當前 state，可寫成固定的 legality predicate

\operatorname{Enabled}(s,a).

這類 puzzle 更自然地建模為 partial reversible transition system 或 groupoid-like structure，而不是強迫塞入一個「每個生成元 everywhere-defined」的單一群作用。這一區分可以涵蓋 shape-changing、bandaged 或 alignment-constrained puzzle，同時仍將它們保留在本文的 Static Twisty Computation 範圍內。只要

A_t=A(s_t)

由一個固定不變的函數決定，系統仍是 stationary；真正的 Dynamic Cube 將在未來允許規則、目標或轉移律本身隨時間、事件或外部 agent 改變。

本文還把 geometry 從 semantics 中解耦。Puzzle 可以沒有可用的 $2D$ net、沒有唯一的 polyhedral embedding，甚至主要以 permutation / graph 形式存在；只要 canonical state、moves 與 goal 定義清楚，它仍然是可計算的 twisty puzzle。當代 cubing.js 的 KPuzzleDefinition 已採用 name + orbits + defaultPattern + moves + derivedMoves 的結構，而 PuzzleGeometry 能輸出 permutations、3D geometry、SVG 與 KPuzzle definition，說明「orbit-first puzzle definition + optional geometry」在現代工具鏈中具有實際可行性。另有數學工作已把 Rubik-like move group 泛化到任意 $3$ -valent map，顯示「Rubik structure」本身也可以超出單一立方體幾何。

本文最後定義 PuzzleSpec、OrbitSpec、MoveSpec、GoalSpec、MetricSpec、NotationSpec、GeometryAdapter 與 CapabilityProfile，並提出 solver capability negotiation：不是每一個 solver 都必須支援每一顆 puzzle，也不是每一顆 puzzle 都必須具備 FCSR flat net、Two-Phase 或 PDB；系統應根據 puzzle 結構與 solver 能力自動決定哪些 representation、heuristic、search 與 proof modules 可用。

至此，FCSR/FDRS 經典線完成從「一顆魔方」到「一類固定規則有限離散 twisty systems」的抽象提升，並為下一篇 Static-Domain Closure 以及後續 Dynamic Twisty Systems 建立精確邊界。

關鍵詞： twisty puzzle、PuzzleSpec、orbit、orientation、partial transition、group action、groupoid、polyhedra、KPuzzle、PuzzleGeometry、FCSR、FDRS

1. 第九篇的任務：把「Cube」從核心型別拿掉

前八篇大量使用：

8\text{ corners},

12\text{ edges},

54\text{ facelets}.

這些對 $3\times3\times3$ 正確。

但若直接擴張到：

$2\times2\times2$ ；
$4\times4\times4$ ；
Pyraminx；
Skewb；
Megaminx；
FTO；
Icosahedral twisty puzzles；
bandaged puzzles；

這些常數立即失效。

因此第九篇的核心目標是：

\boxed{ \text{3x3-specific semantics} \rightarrow \text{TwistyPuzzleSpec}. }

2. 不是所有 twisty puzzle 都應先被描述成「六面」

Cube-centric model 常以：

\text{face} \rightarrow \text{face turn}

作為第一語言。

但 tetrahedral、octahedral、dodecahedral、icosahedral 或 edge / vertex turning puzzles 的自然轉動軸不同。

因此 spec 應以：

\text{piece orbits} + \text{transformations}

為核心，而不是固定：

\text{six faces}.

Geometry 可以描述「這個 transformation 對應哪一個實體轉軸」。

但 transformation semantics 不依賴它一定是一個 cube face。

3. Orbit-first model

令 puzzle 有 orbit 集：

\mathcal O = \{O_1,\ldots,O_r\}.

一個 orbit 代表在 move group / transition structure 下屬於同一類型、可互相交換位置的 pieces。

每個 orbit：

O_i

定義：

名稱；
位置數：

n_i;

orientation modulus：

m_i.

若 piece 沒有可觀察 orientation：

m_i=1.

若是一般 edge flip 類：

m_i=2.

若是一般 corner twist 類：

m_i=3.

但 generalized spec 不把：

m_i\in\{1,2,3\}

寫死。

4. Orbit raw state

對 orbit：

O_i,

piece permutation：

\pi_i\in S_{n_i}.

orientation：

o_i\in\mathbb Z_{m_i}^{n_i}.

所以 raw orbit state 可表示為：

x_i = (\pi_i,o_i).

在標準 composition convention 下，permutation 會重新索引 orientation，因此自然具有 semidirect-product 結構：

\boxed{ X_i \cong S_{n_i} \ltimes \mathbb Z_{m_i}^{n_i}. }

這是 cubie-level model 的一般化。

5. Raw global state

所有 orbits 的 raw product：

X_{\mathrm{raw}} = \prod_{i=1}^{r} \left( S_{n_i} \ltimes \mathbb Z_{m_i}^{n_i} \right).

這只是資料結構上可能的狀態。

它不代表每個 tuple 都 legal。

如同 $3\times3\times3$ ：

X_{\mathrm{legal}} \subsetneq X_{\mathrm{raw}}.

6. 不要為每一顆 puzzle 手寫一套 closed-form legality theorem

$3\times3\times3$ 有漂亮的：

\sum o_c=0\pmod3,

\sum o_e=0\pmod2,

\operatorname{parity}(\pi_c) = \operatorname{parity}(\pi_e).

但 generalized puzzle 未必有同一組約束。

所以通用定義不應要求：

cornerTwistConstraint
edgeFlipConstraint
parityConstraint

一定存在。

更穩定的定義是：

\boxed{ X_{\mathrm{legal}} = \operatorname{Reach}(x_\star) }

其中：

x_\star

為 default solved pattern。

7. Legal state as reachable component

給定 move relation：

T,

定義：

x\in X_{\mathrm{legal}}

若存在合法 move sequence：

p

使：

T^\ast(x_\star,p)=x.

因此 legal state 是：

\boxed{ \text{solved state 的 reachable component}. }

若 puzzle 屬於 total group-action case，這等價於：

G\cdot x_\star.

若 moves 是 state-dependent partial transformations，則使用 reachable transition component 更一般。

8. MoveSpec

每個 primitive move：

a

應定義：

MoveSpec
  id
  orbitTransformations
  inverse
  order
  notationTokens
  geometryRef
  enabledPredicate

其中 orbitTransformations 對每個 orbit 保存：

permutation；
orientation delta。

9. Orbit transformation

對 orbit：

O_i,

move：

a

的 transformation：

M_{a,i} = (\sigma_{a,i},\delta_{a,i}).

其中：

\sigma_{a,i}\in S_{n_i}

是位置 permutation，

\delta_{a,i} \in \mathbb Z_{m_i}^{n_i}

是 orientation change。

對 state：

(\pi_i,o_i),

move composition 必須依固定 convention 更新 permutation 與 orientation。

這正是第二、三篇 cubie semantics 的一般化。

10. Move order

move order：

\operatorname{ord}(a)=k

表示：

a^k=e

且：

k

最小。

Cube quarter turn 常有：

k=4.

但 generalized puzzle 的 move order 可以不同。

因此 UI 不應假設所有 move 都只有：

clockwise
counterclockwise
double

三種 variant。

11. Derived moves

很多 notation 不是 primitive generator，而是：

a = b_1b_2\cdots b_k.

因此 spec 可允許：

derivedMoves

把語法 token 映射成 move sequence。

當代 KPuzzleDefinition 也明確包含 optional derivedMoves，同時具有 orbits、defaultPattern 與 moves。這提供了現有工程基線。

12. DefaultPattern

定義：

x_\star

作為 default solved pattern。

但 generalized puzzle 的「solved」未必只是一個 state。

例如中心 orientation 可忽略、整體 puzzle orientation 可忽略，或多個外觀等價狀態皆可接受。

所以應區分：

\text{defaultPattern}

與：

\text{goalPredicate}.

13. GoalSpec

定義：

G: X_{\mathrm{legal}} \rightarrow \{\mathrm{true},\mathrm{false}\}.

標準單一 solved state：

G(x) \iff x=x_\star.

若忽略整體旋轉或某些 center orientations，可有：

G(x) \iff x\sim x_\star.

所以 GoalSpec 必須是一級規格，而不是把：

state == defaultPattern

寫死。

14. MetricSpec

move cost：

c: (X,a,X') \rightarrow \mathbb R_{\geq0}.

經典 metric 可以是：

quarter-turn metric；
half-turn metric；
slice-turn metric；
puzzle-specific move count。

因此 solver output：

C(p)

只有在：

\operatorname{MetricSpec}

固定後才有意義。

15. NotationSpec

符號不是 semantics 本身。

Move：

a

可能顯示為：

另一個 puzzle 使用：

R++

或 vertex-turn token。

因此：

\boxed{ \text{Move ID} \neq \text{Notation Token}. }

NotationSpec 負責：

parse；
print；
aliases；
derived algorithms。

MoveSpec 負責真正 transformation。

16. GeometryAdapter

Geometry 不進入 canonical algebraic state 的必要核心。

定義 optional：

GeometryAdapter
  pieceMeshes
  stickerGeometry
  axes
  cuts
  cameraDefaults
  flatViews
  pickingMap

這使 puzzle 即使只有 permutation spec，也可以先被 solver / verifier 使用。

等 geometry adapter 加入後，再得到 3D / 2D viewer。

17. 為什麼 geometry 必須 optional

某些 puzzle 可能：

只有抽象圖定義；
還沒有建模 mesh；
$2D$ 展開不自然；
有多種外觀但相同 algebraic puzzle；
是 shape modification。

若 solver kernel 依賴 mesh：

\text{no geometry} \Rightarrow \text{no computation},

架構就倒置了。

正確順序：

\boxed{ \text{Semantics first, geometry optional}. }

18. 同一 algebraic puzzle 可以有多個 geometry skins

若：

\mathcal P_{\mathrm{alg}}

固定，

可能存在：

\Gamma_1,\Gamma_2,\ldots

多個 geometry adapters。

例如 shape mod 可以在保留核心 transformation structure 的同時改變外觀與人類辨識方式。

所以：

\boxed{ \text{geometry identity} \neq \text{algebraic identity}. }

這對 FDRS 的 representation 理論非常重要。

19. Total reversible move system

第一類 classical puzzle：

對所有：

s\in X_{\mathrm{legal}},

所有 primitive move：

a\in A,

都有：

T(s,a)

定義。

且存在 inverse：

a^{-1}.

這時候：

A

生成有限群：

G.

legal state：

G\cdot x_\star.

標準 $3\times3\times3$ 屬於此類。

20. Partial reversible move system

第二類 classical puzzle：

某些 move：

a

只有在：

\operatorname{Enabled}(s,a)

成立時可執行。

定義 partial transition：

T: X\times A \rightharpoonup X.

若：

T(s,a)=s',

則仍要求存在 inverse transition：

T(s',a^{-1})=s.

所以局部 transition 仍可逆。

21. 為什麼需要 partial transition

這能表達：

alignment-dependent moves；
shape-changing puzzles；
bandaged puzzles；
mechanism-constrained turns。

關鍵是：

\operatorname{Enabled}

本身仍是一個固定規則。

所以它不是本文未來所說的 Dynamic Cube。

22. Static 不等於 $A(s)$ 為常數

Static puzzle 可以有：

A(s) = \{a:\operatorname{Enabled}(s,a)\}.

只要：

A(\cdot)

這個函數本身在整場 puzzle 中不變。

也就是：

\boxed{ A_t=A(s_t) }

而不是：

A_t = A(s_t,t,E_t,\text{external agent})

隨外部世界改規則。

23. Group-action 與 groupoid-like 兩層語言

對 total moves，使用：

G\curvearrowright X.

非常自然。

對 partial moves，更自然的是把合法 states 當 objects、合法 reversible transitions 當 arrows。

若：

s\xrightarrow{a}s',

就是一個 arrow。

每個 arrow 有 inverse。

可合成的 arrows 依路徑合成。

這具有 groupoid-like 結構。

本文不要求第一版 runtime 實作完整 category / groupoid library，但規格語言不能假裝所有 puzzle 都是 everywhere-defined group action。

24. 這仍然是「傳統問題」

即使 move availability 依 state，

只要：

rule fixed；
goal fixed；
transition law fixed；
environment 不主動改變；

它仍是一個 static finite puzzle。

因此：

\boxed{ \text{state-dependent legality} \neq \text{dynamic rules}. }

這個邊界留到第十篇再次封閉。

25. PuzzleSpec v0

本文提出：

TwistyPuzzleSpec
  id
  name
  orbits
  defaultPattern
  primitiveMoves
  derivedMoves
  goal
  metric
  notation
  legalityModel
  capabilityHints
  geometryAdapters
  provenance
  version

這是系列後續實作的核心規格。

26. OrbitSpec

OrbitSpec
  id
  pieceCount
  orientationModulus
  labels
  indistinguishability
  displayRole

indistinguishability 是重要欄位。

某些 puzzle pieces 在外觀上可能不可區分，但 algebraic model 仍可選擇把它們標記成 distinguishable pieces，再由 goal / representation 層商掉。

27. Indistinguishable pieces

若 pieces：

p_i,p_j

在 puzzle goal 上不可區分，則 physical solved equivalence 可能比 labeled algebraic state 更粗。

因此：

\text{labeled state count}

可能大於：

\text{visually distinct state count}.

solver 與 UI 都必須知道正在使用哪個 quotient。

不能只說：

這顆 puzzle 有 $N$ states

卻不說 pieces 是否被視為 distinguishable。

28. Orientation convention

orientation 不只需要 modulus：

m_i.

還需要 convention。

同一 physical orientation 可能因 reference frame 定義不同而得到不同數值。

所以 OrbitSpec / RepresentationSpec 應保存：

orientationConventionId

並要求 move transformations 與 parser 使用同一 convention。

29. Facelets 不再是 canonical 必需品

某些 puzzle 有：

tiles；
stickers；
uncolored pieces；
shape cues；
orientation marks。

因此 generalized core 不應要求：

\mathcal C^{N}

facelet array 一定存在。

Facelet representation 只是 optional adapter：

R_{\mathrm{facelet}}.

30. Flat Net 也不再是 canonical 必需品

FCSR 起源來自 flat net。

但 generalized FCSR 應允許：

R_{\mathrm{flat}} = \varnothing.

若 puzzle 沒有自然、清晰、保結構的 2D net，就不要硬做。

第八篇已指出 modern viewer 也存在部分 puzzle 無 $2D$ visualization 的情況。

因此：

\boxed{ \text{FCSR origin is flat; FDRS generalization is representation-selective}. }

31. Graph view 是更一般的 fallback

如果沒有 natural flat geometry，可以使用：

R_{\mathrm{graph}}: X \rightarrow \mathcal G.

graph 可以表示：

piece adjacency；
orbit membership；
move incidence；
state transitions；
constraint structure。

因此 generalized viewer 至少可以保有抽象 graph representation。

32. Solver capability 不應假設 universal

定義 solver capability：

SolverCapability
  requiresTotalMoves
  supportsPartialMoves
  requiresUnitCost
  supportsWeightedMetric
  requiresGroupAction
  supportsMultipleGoals
  requiresCoordinates
  supportsPDB
  proofLevel

某個 Two-Phase solver 可能只支援：

3\times3\times3.

這不是 bug。

只要 capability declaration 清楚。

33. Capability negotiation

給 puzzle：

\mathcal P

與 solver：

S,

系統計算：

\operatorname{Compatible}(S,\mathcal P).

若 false，不應讓 UI 顯示一個會 crash 的：

Solve

按鈕。

而應顯示：

Solver unavailable
reason: requires total move action

或：

reason: no compatible heuristic representation

34. Heuristic capability

heuristic 也需要 capability：

HeuristicCapability
  puzzleSpecId
  representation
  metric
  admissible
  consistent
  stateDomain

PDB：

h

若是在 HTM 建構，就不能直接被當成 QTM lower bound 使用，除非另有證明。

因此 metric 也是 heuristic certificate 的一部分。

35. Search Kernel generalized interface

第四篇的：

\mathcal Q = (X,A,T,G,c,h)

現在改成由 PuzzleSpec 生成。

對 total puzzle：

A(x)=A.

對 constrained puzzle：

A(x) = \{a:\operatorname{Enabled}(x,a)\}.

所以 BFS、A*、IDA* 本身不必知道 puzzle 是 cube、dodecahedron 或其他 polyhedron。

它只需要：

successors(state)
goal(state)
cost(edge)
heuristic(state)

36. Verification Kernel generalized interface

第七篇的 checker 同樣泛化：

\operatorname{checkSolution}_{\mathcal P}(s,p).

它逐步檢查：

move token 是否解析；
move 是否 enabled；
transition 是否合法；
final goal 是否成立。

因此 partial-move puzzle 的 certificate checker 會比 total group puzzle 多一個：

\operatorname{Enabled}

驗證。

37. Legal-state verification 的兩種模式

Constructive

若 state 是由：

x_\star

重播合法 move sequence 得到，legality 自帶 witness。

Imported state

若使用者從 UI / scanner 直接輸入 state，則需要 puzzle-specific validator。

因此：

StateProvenance
  DerivedFromSolved(path)
  ParsedAndValidated(certificate)
  UnverifiedImport

可以成為 canonical metadata。

38. Geometry-derived puzzle spec

當代 PuzzleGeometry 類工具展示了一個很有價值的方向：

\text{Puzzle Geometry Description} \rightarrow \text{Orbits / Moves / Permutations / 3D / SVG}.

其 API 可產生：

getKPuzzleDefinition；
getMovesAsPerms；
get3d；
generatesvg。

這說明 geometry compiler 可以作為 PuzzleSpec generator。

但生成結果仍應經：

\text{semantic validation}

後才進 canonical registry。

39. Algebra-derived geometry

反方向也可以：

\text{PuzzleSpec} \rightarrow \text{GeometryAdapter}.

若已有：

orbits；
moves；
labels；

可以再指定：

piece meshes；
axes；
cuts；
sticker maps；

形成可視化。

所以 geometry 與 algebra 之間是雙向工具鏈，而不是單一依賴關係。

40. Polyhedral puzzle

對 polyhedron：

P=(V,E,F),

可以以：

face；
edge；
vertex；

作為 geometric features。

但 piece orbits 不必和：

V,E,F

一一相等。

不同 cutting scheme 會產生不同 pieces 與 move groups。

因此：

\boxed{ \text{same base polyhedron} \neq \text{same twisty puzzle}. }

41. Turning type 應是 geometry metadata

Face-turning、edge-turning、vertex-turning 是人類非常有用的分類。

所以可保存：

turningType:
  face
  edge
  vertex
  hybrid
  custom

但 canonical move semantics 仍由：

M_a

決定。

分類標籤不取代 transformation data。

42. 從 Platonic solids 到更一般 map

傳統 twisty polyhedra 常建立在：

tetrahedron；
cube；
octahedron；
dodecahedron；
icosahedron；

等幾何上。

但 generalized Rubik-like mathematics 不必停在五種 Platonic solids。

Mathieu Dutour Sikirić 的工作把 Rubik-like move group 泛化到任意 $3$ -valent map，並研究相應群的大小上界。

這說明：

\boxed{ \text{Rubik-like combinatorics} }

可以由：

\text{map / incidence structure}

而不只由實體 cube geometry 驅動。

43. Map-based puzzle spec

更抽象時，可讓：

\mathcal M

為 combinatorial map。

定義：

cells；
adjacency；
local rotations；
move generators。

再生成：

\mathcal P(\mathcal M).

這為未來程序生成陌生 twisty puzzle 留下數學入口。

44. 程序生成 puzzle

如果 PuzzleSpec 已抽象化，就可以生成：

GeneratePuzzle(seed)
  -> orbits
  -> moves
  -> goal
  -> geometry optional

然後驗證：

moves 可逆；
solved state well-defined；
legal component finite；
puzzle 非平凡；
goal reachable。

這比只收藏現有商品 puzzle 更接近 AI benchmark。

但程序生成仍屬後續工程，不是本文 immediate implementation requirement。

45. Puzzle identity 與 version

PuzzleSpec 必須 versioned。

例如：

puzzleId: megaminx-standard
specVersion: 1.0.0
notationVersion: 1
metricVersion: htm-like-1

因為 certificate：

p

只有在 move semantics 固定時才可重播。

46. PuzzleSpec fingerprint

定義 canonical serialization：

\operatorname{Ser}(\mathcal P).

再取：

H_{\mathcal P} = \operatorname{SHA256} ( \operatorname{Ser}(\mathcal P) ).

SolutionCertificate 保存：

H_{\mathcal P}.

這保證 verifier 知道自己正在用哪一份 puzzle ruleset。

注意 checksum 驗證的是 spec identity，不是數學正確性。

47. Derived representation registry

每個 PuzzleSpec 可註冊：

\mathcal R_{\mathcal P} = \{R_1,\ldots,R_k\}.

可能包括：

3D；
flat；
orbit table；
facelet；
coordinate；
symmetry；
search graph；
proof view。

不是所有 puzzle 都有全部 representations。

48. CapabilityProfile

定義：

CapabilityProfile
  totalMoveAction
  partialMoveAction
  geometry3D
  geometry2D
  faceletView
  orbitView
  coordinateView
  symmetryData
  exactLegalityChecker
  solverIds
  heuristicIds
  formalProofLevel

UI 根據 capability 自動組合，而不是每顆 puzzle 手寫頁面。

49. $2\times2\times2$ 作為第二個實例

$2\times2\times2$ 沒有 edge orbit 與固定 face centers。

它可以測試：

我們的 core 是否真的沒有偷偷依賴 $12$ edges？

Orbit 主要是：

O_c

with：

n_c=8, \quad m_c=3.

這是 generalized core 的第一個 regression puzzle。

50. $3\times3\times3$ 作為 reference instance

$3\times3\times3$ 保留：

O_c: (8,3),

O_e: (12,2).

若追蹤 centers：

O_z

可依 representation / supercube requirement 決定 orientation semantics。

它是目前 proof / solver / visualization 功能最完整的 reference implementation。

51. $4\times4\times4$ 作為 orbit stress test

$4\times4\times4$ 引入：

additional centers；
paired wing-like edge pieces；
inner slice moves；
不同 parity phenomena。

這能測試：

多 orbit；
derived piece grouping；
solver capability；
representation scalability。

因此它比單純把 $N$ 改成 $4$ 更有價值。

52. Pyraminx / Skewb 作為 turning-axis stress test

這類 puzzle 可以測試：

runtime 是否仍把 move 當 cube face turn？

如果核心只接受：

face: U/D/L/R/F/B

立即失敗。

正確核心只接受：

\operatorname{MoveId}.

geometry adapter 才解釋其實體轉軸。

53. Megaminx 作為 non-cubic polyhedron stress test

Megaminx 測試：

dodecahedral geometry；
更多 face axes；
更大 notation set；
多面 flat visualization；
UI scaling。

若 FCSR 仍只能畫十字 net，就代表第八篇的 generalized viewer 尚未完成。

54. Icosahedral puzzle 作為高面數 stress test

二十面體或相關 twisty puzzle 特別適合原始研究動機：

當面數與局部關係增加時，不同 observer representations 的可理解性如何變化？

這裡 FDRS 的 representation-selection 實驗比「人類背公式」更有價值。

55. 多 puzzle benchmark 不應只比解速

定義 benchmark vector：

B(\mathcal P,S) = ( C_{\mathrm{solve}}, M, N_{\mathrm{exp}}, L, V, P ).

其中：

$C_{\mathrm{solve}}$ ：計算時間；
$M$ ：記憶體；
$N_{\mathrm{exp}}$ ：展開節點；
$L$ ：解長；
$V$ ：verification coverage；
$P$ ：representation / visualization coverage。

如此更符合本系列目標。

56. Puzzle complexity profile

對 puzzle：

\mathcal P,

不只報：

|X_{\mathrm{legal}}|.

還可報：

orbit count；
generator count；
move orders；
state-dependent move ratio；
symmetry group size；
average effective branching；
known diameter / bound；
representation cardinalities；
heuristic availability。

這比單一 state count 更能描述計算形狀。

57. FDRS representation experiment generalized

對同一 puzzle：

\mathcal P,

比較：

R_1,\ldots,R_k.

測：

C_{\mathrm{search}} ( \mathcal P,R_i,A,h ).

再跨 puzzle：

\mathcal P_1,\ldots,\mathcal P_m.

可以研究：

\boxed{ \text{哪一類 representation 對哪一類 twisty structure 最有效？} }

這已經從「魔方技巧」提升成 representation engineering。

58. FDRS 不預設低維必勝

某個 Megaminx 或高面數 puzzle 的最佳 solver representation 可能：

不是 2D；
不是 geometry；
是 orbit coordinate；
是 quotient graph；
是 mixed representation。

所以 generalized principle 是：

\boxed{ \text{選最適任務表示，而不是固定追求最低幾何維度}. }

這是 2025 起源論述經過九篇重建後最重要的修正之一。

59. Formalization strategy

Lean 不應先形式化所有現存 puzzle。

先形式化 generic kernel：

OrbitSpec
MoveTransformation
PuzzleSpec
State
applyMove
applyMoves
Goal
Solves

再做 instances：

Cube2
Cube3

之後逐步增加其他 puzzle。

60. Generic total-move theorem

若：

a

的每個 orbit transformation 都是 permutation + orientation update，且具有 inverse：

a^{-1},

則：

T_{a^{-1}}(T_a(s))=s.

這個 theorem 可在 generic orbit kernel 證一次。

所有 total-move puzzle instances 自動繼承。

61. Generic partial-move theorem

對 partial puzzle：

若：

\operatorname{Enabled}(s,a)

且：

T(s,a)=s',

要求：

\operatorname{Enabled}(s',a^{-1})

以及：

T(s',a^{-1})=s.

這成為 constrained static puzzle 的 reversible-transition contract。

62. Generic solution checker

對任意 PuzzleSpec：

\operatorname{checkSolution}_{\mathcal P}(s,p)

逐步：

檢查 move token；
檢查 enabled；
apply transition；
最後檢查 goal。

其 soundness theorem 可通用證明一次：

\boxed{ \operatorname{checkSolution}_{\mathcal P}(s,p)=\mathrm{true} \Rightarrow \operatorname{Solves}_{\mathcal P}(s,p). }

這是第七篇架構向 multi-puzzle 的最重要升級。

63. Generic visualization contract

對可用 representation：

R_i^{\mathcal P},

要求：

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

所以第八篇同步框架也可以 generic 化。

64. Generic search contract

第四篇的：

\mathcal Q = (X,A,T,G,c,h)

由：

\mathcal P

與：

R

共同生成：

\mathcal Q(\mathcal P,R).

搜尋器因此不需要知道：

這是一顆五魔方還是十二面體。

只需要其 search contract。

65. 產品層：Puzzle Gallery 不是固定頁面集合

未來 UI 可以讀 registry：

PuzzleRegistry
  cube2
  cube3
  cube4
  pyraminx
  skewb
  megaminx
  ...

點入 puzzle 後由 CapabilityProfile 自動組合：

view tabs；
solver buttons；
proof panels；
available metrics；
notation help。

這比每顆 puzzle 寫一套 app 更可維護。

66. Import / export

通用 artifact：

puzzle-spec.json
state.json
algorithm.txt
solution-certificate.json
verification-report.json

若有 geometry：

geometry.json
mesh/*

若有 heuristic：

pdb/*
heuristic-metadata.json

這為之後整包 ZIP 與研究資料庫留下標準。

67. Canonical source 與 renderer 分離

正式規格必須保存：

\operatorname{PuzzleSpec}.

HTML viewer、3D renderer、SVG 只是 rendering artifacts。

因此：

\boxed{ \text{viewer is not the canonical puzzle definition}. }

這也避免未來只能從網頁程式逆向提取 puzzle rules。

68. 外部規格 adapter

cubing.js 的 KPuzzleDefinition 可以作為 import / export adapter。

它目前包含：

name；
orbits；
defaultPattern；
moves；
optional derivedMoves。

這和本文 Orbit-first spec 高度相容。

但 FCSR TwistyPuzzleSpec 還需額外保存：

goal；
metric；
legality model；
proof metadata；
capability profile；
version / fingerprint。

所以不是直接等同。

69. PuzzleGeometry adapter

PuzzleGeometry 目前能：

產生 SVG；
產生 3D sticker geometry；
產生 permutations；
產生 KPuzzle definition；
產生 scramble / solved permutation；
輸出其他數學工具格式。

因此它可以作為：

\boxed{ \text{geometry compiler / importer} }

而不是 FCSR canonical solver core。

70. 研究邊界：通用規格不等於通用 solver

建立：

\operatorname{TwistyPuzzleSpec}

不代表立刻存在：

\operatorname{UniversalOptimalSolver}.

通用規格解決的是：

系統能否精確描述、重播、驗證、可視化與交給 solver？

不是：

所有 puzzle 都能同樣快地最短求解。

所以：

\boxed{ \text{Universal Representation Layer} \neq \text{Universal Efficient Solver}. }

71. 本文核心命題

命題 G-A： $3\times3\times3$ 應成為 spec instance

而不是核心型別。

命題 G-B：Orbit 是比 cube face 更一般的 canonical state primitive

X_i \cong S_{n_i} \ltimes \mathbb Z_{m_i}^{n_i}.

命題 G-C：Legal state 最一般地由 reachable component 定義

X_{\mathrm{legal}} = \operatorname{Reach}(x_\star).

命題 G-D：Static puzzle 可以有 state-dependent enabled moves

A(s)

不必為常數。

命題 G-E：State-dependent legality 不等於 Dynamic Rules

只要：

A(\cdot)

本身固定。

命題 G-F：Geometry 是 optional adapter

不是 canonical semantics。

命題 G-G：Solver / heuristic / visualization 都應 capability-negotiated

而不是假設 universal。

命題 G-H：Generic certificate checker 可以跨 puzzle 重用

只要 PuzzleSpec 提供 canonical transition 與 goal semantics。

72. 結論

本文完成經典系列從：

\text{Rubik's Cube}

到：

\boxed{ \text{Twisty Puzzle} }

的正式抽象化。

通用 puzzle 不再由：

6\text{ faces} + 54\text{ stickers}

定義。

而由：

\boxed{ \text{Orbits} + \text{Orientations} + \text{Moves} + \text{Legality} + \text{Goal} + \text{Metric} + \text{Notation} + \text{Optional Geometry}. }

對 total reversible puzzles，可使用：

G\curvearrowright X.

對固定規則但 move availability 依 state 的 constrained puzzles，可使用：

T: X\times A \rightharpoonup X.

兩者都仍屬：

\boxed{ \text{Static Twisty Computation}. }

因為規則、目標與 transition law 本身沒有在遊戲過程中外生改變。

這一區分非常重要。

它讓我們在下一篇可以精確回答：

經典 twisty puzzle 的「靜態」究竟意味著什麼？

也讓後續 Dynamic Cube 不需要靠「亂加會變的規則」來定義，而可以嚴格寫出：

\boxed{ \text{何時 stationary puzzle specification 被解除。} }

到第九篇，FCSR 的原始魔方已不再是一個被丟棄的玩具例子。

它變成了一條完整抽象鏈的起點：

\boxed{ \text{Cube} \rightarrow \text{Canonical State} \rightarrow \text{Representation} \rightarrow \text{Search} \rightarrow \text{Verification} \rightarrow \text{TwistyPuzzleSpec}. }

下一篇將封頂本系列：

《經典域封頂：Static Twisty Computation 的邊界與 Dynamic Cube 的前置條件》。

參考資料與來源定位

起源與系列內部

[F2025-A] Neo.K，《展平式維度重構理論：完整數學架構與概念解析》。
[F2025-B] Neo.K，《展平式維度重構理論：從 FCSR 到 FDRS 的完整數學架構》。
[CUBE-01] 至 [CUBE-08]：本系列前八篇。

當代工程基線

[R1] cubing.js, KPuzzleDefinition API reference。其結構包含 name、orbits、defaultPattern、moves 與 optional derivedMoves。
[R2] cubing.js, PuzzleGeometry API reference。其功能包含 SVG、3D geometry、permutations、KPuzzle definition 與其他 puzzle-geometry 輸出。
[R3] cubing.js, TwistyPlayer documentation。作為多 puzzle playback 與 optional 2D visualization 的現代 viewer 基線。

數學泛化基線

[R4] Mathieu Dutour Sikirić, A variation on the Rubik's cube, 2020。將 Rubik-like puzzle group 泛化到任意 $3$ -valent map，研究對應群大小上界。

版本註記

v0.1 首次將 FCSR/FDRS 魔方線提升成通用 TwistyPuzzleSpec，並明確區分 total group-action puzzles 與 fixed-rule partial reversible puzzles。

本文保留「state-dependent enabled moves」在 Static Twisty Computation 內，將真正 Dynamic Cube 留給規則、目標、transition law 或外部環境本身發生時間性變化的後續系列。

後續第十篇：