工作流程：透過 HTTP API 依條件為步著色¶

透過 HTTP API 進行重播驗收以一次播放完整個任務、並憑證據驗收過的執行收尾。本頁透過 HTTP API，依步屬性上的條件——也就是一棵著色樹——把那次執行的步分成幾類，並回報每一類在步數與加工時間中所占的比例，給沒有畫布可看的腳本或代理程式 (agent) 使用。它是為可能有別人正在看著的執行個體而寫的：§1 到 §4 既不改專案，也不改任何人看到的顏色；§5 加入著色樹，而不覆蓋別人放上去的那棵；唯一會改變每個畫面上顏色的那一節——§6——是選擇性的，並在結束時把顏色設回原樣，除非這段期間有別人改了視覺指標。

登入、回應封套，以及這裡每一條路由都遵循的其他約定，見透過 HTTP 驅動網頁服務（英文，未鏡像）。下面用到的每一條路由、每個欄位與每個回應代碼，都在透過 HTTP 操作著色樹（英文，未鏡像）裡；樹怎麼把步分類、怎麼替它的葉著色，見著色樹（英文，未鏡像）。在瀏覽器裡建同一棵樹，見步著色：那裡每個節點在加入時編號——新樹一開始就有的那片葉 Cut 是 1——所以各片葉的編號，連同由編號而來的自動色相，都和這裡的不同。下面每個本體都是 JSON，以 Content-Type: application/json 送出。

flowchart LR
    Look["先看<br>保留視覺指標"]
    Write["寫出著色樹"]
    Check["檢查"]
    Preview["試算<br>各葉的占比"]
    Put["PUT<br>只新增"]
    Show["顯示在畫面上<br>只在被要求時"]
    Back["把視覺指標<br>設回去"]
    Save["儲存"]

    Look --> Write --> Check --> Preview --> Put --> Save
    Check -->|有問題| Write
    Preview -->|409，再送一次| Preview
    Put -.->|上畫面| Show --> Back --> Save

1. 先看，並保留視覺指標¶

這一節的每個請求都只讀取，不改變任何東西。先看執行：

GET /api/Execution/status

executionStatus 是 Finished。保留 runId、instanceId，以及它們旁邊的 resetCount：§4 會再讀一次，以確知它數過的步仍是這次執行的。Running 或 Paused 表示有一次播放正在改變下面每個請求所讀的步——等它結束，而且絕不停止或重置一次你無法證明是自己的執行。NoProject 表示沒有開啟任何專案。

GET /api/execution/cl-strip/range

count 是步序列上的位置數，大於 0；下文寫成 <count>。接著讀專案的著色樹、樹能讀的鍵，以及視覺指標：

GET /api/execution/step-color-trees?lang=en

回應是 { success, generation, physicsShown, inspectingKey, builtInTrees, trees, registeredAtRun, keyOptions }；沒有開啟專案時，則是 success: false，code 為 NoProjectLoaded。

inspectingKey 就是視覺指標：視覺指標時序圖所畫、3D 畫布據以替刀具路徑與切削面著色的那個步屬性，是每個連線的畫面都跟著走的專案設定。把它原封不動地保留下來，null 也一樣：§4 會核對它，§6 在設定另一個之前也會再讀一次。不帶鍵的 GET /api/execution/strip-chart-item-config，會在它的 inspectingKey 回答同一個值。GET /api/execution/step-properties 的 currentKey 不是它：物理鍵隱藏著、而視覺指標正是其中之一時，那個欄位指名的是代替它顯示的鍵。
keyOptions 是條件項能指名的步屬性，每個都是 { key, name, unit, unitLabel, kind, isPhysics, source }。§2 的鍵都在其中：IsRapid 與 IsTouched，kind 為 bool；physicsShown 為 true 時，還有那三個比值，kind 為 quantity、isPhysics 為 true。
physicsShown 為 false——顯示物理選項沒開，或沒有物理授權——時，keyOptions 不列出物理鍵，check 與 PUT 也會對樹指名的每一個物理鍵提出警告；樹照樣讀它們。讓偏好設定維持原樣：它屬於這個執行個體，所有使用者共用。
trees 與 registeredAtRun 分別是專案定義的著色樹，以及任務腳本為這個工作階段註冊的著色樹。其中若已有一棵樹問的正是這個問題，而它是 registeredAtRun 之一，或它的 state 是 registered——依鍵試算讀得到的就是這些樹——就不必再複製一棵：依它的鍵試算（§4），並據此回報。
builtInTrees 是 HiNC 自己的樹，唯讀（工程面向著色）：MachiningState，加工狀態，要讀物理，把每一步放進碰撞、快移切料、依負載判讀的九片切削葉之一——應力超限、主軸扭矩持續超載、主軸功率持續超載、主軸扭矩短暫超載、主軸功率短暫超載、主軸過熱、負載未評估、熱應力超限、正常切削——空切或快移；MachiningStateGeometry，加工狀態（不含物理），只憑播放本身，就把每一步放進碰撞、快移切料、切削（負載未評估）、空切或快移。其中一棵回答得了這個問題時，依它的鍵試算（§4），並據此回報，連同它的圖表註記對這些步的說明（內建樹的註記 (Notes of a Built-in Tree)（英文，未鏡像））。其中一棵很接近這個問題時，就從它開始：它的 tree 就是 §2 寫的那種形狀，所以把它當作 §2 的樹，在 PUT 之前把它的 key 改成你自己的鍵——check 不看鍵，但本體的鍵仍是 MachiningState 或 MachiningStateGeometry 的 PUT 會被拒絕，400 StepColorTreeKeyTaken——再改這個問題需要改的地方，各節點保留它們的編號。要把一棵原樣留在專案裡——隨專案存檔、HiNC 之後的版本不會改它——POST /api/execution/step-color-trees/<它的鍵>/copy 帶著 {"newKey": "<你的鍵>"} 就能複製它；這是對專案的修改，和 §5 的 PUT 一樣，鍵也照同樣的規則拒絕。

繼續之前，先選好樹的鍵：builtInTrees、trees、registeredAtRun 與 keyOptions 裡沒有任何一項用著、也不是 inspectingKey 本身的鍵——被刪除的樹會把它的鍵留作視覺指標，直到有人設了另一個；在那個鍵下加入的樹，會立刻替每個畫面重新著色。內建步屬性的鍵、內建樹的鍵——MachiningState、MachiningStateGeometry——或 MC. 之下的鍵，會被拒絕（400 StepColorTreeKeyTaken；直接在內建樹的鍵之下 PUT，則回應 409 StepColorTreeBuiltIn）；專案步變數的鍵，到 §5 會回應 409；專案的著色樹若用了腳本已註冊的鍵，就會在這個工作階段接手那個鍵。本頁用 LoadCheck。

2. 寫出著色樹¶

一棵樹是一份從頂端往下試的節點清單：第一片條件成立的葉收下這一步，並給它顏色；沒有條件的葉（"when": null）收下每個走到它這裡的步。這裡分成四類：

葉	收下一步的條件
Overload	應力比、主軸最大扭矩比與主軸最大功率比，任一個大於 1
Rapid	它是快移：`IsRapid` 為是
Air	它什麼都沒碰到：`IsTouched` 為否
Cut	其他；時序圖在它的道內畫出它的主軸最大功率比

{"key": "LoadCheck", "name": "Load check", "nodes": [
  {"kind": "leaf", "name": "Overload", "hue": 0, "when": {"join": "any", "terms": [
    {"key": "StressRatio", "op": "gt", "threshold": 1},
    {"key": "MaxSpindleTorqueRatio", "op": "gt", "threshold": 1},
    {"key": "MaxSpindlePowerRatio", "op": "gt", "threshold": 1}]}},
  {"kind": "leaf", "name": "Rapid", "when": {"join": "all", "terms": [{"key": "IsRapid", "op": "eq", "threshold": 1}]}},
  {"kind": "leaf", "name": "Air", "when": {"join": "all", "terms": [{"key": "IsTouched", "op": "eq", "threshold": 0}]}},
  {"kind": "leaf", "name": "Cut", "when": null, "valueKey": "MaxSpindlePowerRatio"}]}

順序就是意義。快移上的超限也是 Overload；快移不論有沒有碰到東西都是 Rapid；Air 收下的是什麼都沒碰到的進給移動。
編號由伺服器給。要加入的樹不帶 id 與 nextId；伺服器依寫出的順序替節點編號——Overload 1、Rapid 2、Air 3、Cut 4——而一片葉的編號，就是樹在它每一步上的值。
是與否讀作 1 與 0，所以 eq 配 1 問的是「是」，配 0 問的是「否」。
沒有值，每個比較都不成立。三個比值只在物理算過的地方有值，兩個主軸比還要專案的主軸能力在那一步的轉速下給得出限制，才會有值：沒有這些值的步不是 Overload，會往下走到下面的葉。
門檻值 1——每個比值的 100 %——是這個範例的選擇，不是 HiNC 定的限制。熱應力比沒有放進 Overload：達 100 % 以上代表扣分加工——損失的是刀具壽命，不是斷刀風險——而且用出貨的、偏保守的熱性質，在刀具廠商建議的切削條件下它通常就達到 100 %（刀刃熱塑性變形）；MachiningState 另給它一片自己的葉——熱應力超限——排在它的各種超限之後，一般的切削也常落進這片葉。
hue 是葉的色相，以度計，這裡只替 Overload 挑了一個；沒有色相的葉，依它的編號自動選色。valueKey 不改任何顏色：它指名視覺指標時序圖在那片葉的道內畫出的值。

3. 檢查¶

POST /api/execution/step-color-trees/check
Content-Type: application/json

{"key": "LoadCheck", "name": "Load check", "nodes": [
  {"kind": "leaf", "name": "Overload", "hue": 0, "when": {"join": "any", "terms": [
    {"key": "StressRatio", "op": "gt", "threshold": 1},
    {"key": "MaxSpindleTorqueRatio", "op": "gt", "threshold": 1},
    {"key": "MaxSpindlePowerRatio", "op": "gt", "threshold": 1}]}},
  {"kind": "leaf", "name": "Rapid", "when": {"join": "all", "terms": [{"key": "IsRapid", "op": "eq", "threshold": 1}]}},
  {"kind": "leaf", "name": "Air", "when": {"join": "all", "terms": [{"key": "IsTouched", "op": "eq", "threshold": 0}]}},
  {"kind": "leaf", "name": "Cut", "when": null, "valueKey": "MaxSpindlePowerRatio"}]}

回應是 { success, problems, messages, referencedKeys }。符合下列各點時，就接受這棵樹：

problems 是空的。一個問題是 { code, path, refuses }，path 是它在本體中的位置，例如 nodes[0].when.terms[2]：refuses: true 的問題會讓樹無法註冊——修正它，再檢查一次；只有 refuses: false 問題的樹會照原樣註冊，附上一則警告。
messages 是空的；或在 physicsShown 為 false 時，帶著三列 id 為 StepColorTree-Term--PhysicsHidden 的訊息，每個比值一列。StepColorTree-Term--KeyUnresolved 這一列，指名的是沒有任何步屬性對應的鍵：拼錯的鍵，在每一步上都讀成沒有值。
referencedKeys 是 ["StressRatio", "MaxSpindleTorqueRatio", "MaxSpindlePowerRatio", "IsRapid", "IsTouched"]，每個都是 keyOptions 的鍵——physicsShown 為 false 時，那三個比值除外。

本體不是照規定寫成的樹時，回應 400，帶著 code 與 args：args 裡有 path，即它在本體中的位置，有些代碼還帶 reason；每個代碼都列在回應代碼 (Answers)（英文，未鏡像）。check 不改任何東西。

4. 在整次執行上試算，讀出占比¶

POST /api/execution/step-color-trees/preview
Content-Type: application/json

{"tree": {"key": "LoadCheck", "name": "Load check", "nodes": [
  {"kind": "leaf", "name": "Overload", "hue": 0, "when": {"join": "any", "terms": [
    {"key": "StressRatio", "op": "gt", "threshold": 1},
    {"key": "MaxSpindleTorqueRatio", "op": "gt", "threshold": 1},
    {"key": "MaxSpindlePowerRatio", "op": "gt", "threshold": 1}]}},
  {"kind": "leaf", "name": "Rapid", "when": {"join": "all", "terms": [{"key": "IsRapid", "op": "eq", "threshold": 1}]}},
  {"kind": "leaf", "name": "Air", "when": {"join": "all", "terms": [{"key": "IsTouched", "op": "eq", "threshold": 0}]}},
  {"kind": "leaf", "name": "Cut", "when": null, "valueKey": "MaxSpindlePowerRatio"}]},
 "range": "all"}

試算讀的是播放過的步本身，什麼也不寫。它的 histogram 就是這個問題的答案：

leaves 依樹的順序列出每片葉，{ id, name, steps, seconds, share, firstStepIndex }：葉收下的步數；它們的仿真時間總和，以秒計；share，這段時間占所有掃過的步之時間的比例；以及其中的第一步，沒有時為 −1。一片葉占步數的比例，是它的 steps 除以 scannedSteps。
noValue，{ steps, seconds, share }，是沒有任何葉收下的步。

selectedStep 說明執行個體上選取的那一步，或為 null；現在還用不到它。憑證據接受這些占比：

檢查	在哪裡	通過條件
讀了整次執行	`histogram`	`range` 是 `all`，`begin` 為 0，`end` 為 `<count>`；`scannedSteps` 是 `<count>` 減去沒有步的位置（建它時失敗、以 `Step-Task--Fault` 回報的步）；`skippedPositions` 為 0
每一步都有分類	`histogram`	各片葉的 `steps` 加上 `noValue.steps` 等於 `scannedSteps`；最後一片是「其他」葉時，`noValue.steps` 等於 `faultedSteps`，也就是讀取失敗的步，並且是 0
比值都算過了	下面那個請求的 `selectedStep`	Cut 的第一步讀到三個比值的數字
視覺指標沒被動過	回應的 `inspectingKey`	§1 保留的那個鍵
仍是 §1 的那次執行	`GET /api/Execution/status`	`runId`、`instanceId` 與 `resetCount` 都和 §1 保留的相同

要看一步為什麼落在它所在的地方，就指名它——這裡是 Cut 的第一步，也就是 name 為 Cut 的那片葉的 firstStepIndex（Cut 沒有收下任何步時為 −1：改指名另一片葉的第一步）。依 name 找 Cut，而不是依號碼：依鍵試算的樹，保有它建立時的編號，而照步著色的操作步驟建出的同一棵樹，是 Cut 1、Overload 2、Rapid 3、Air 4：

POST /api/execution/step-color-trees/preview
Content-Type: application/json

{"tree": {"key": "LoadCheck", "name": "Load check", "nodes": [
  {"kind": "leaf", "name": "Overload", "hue": 0, "when": {"join": "any", "terms": [
    {"key": "StressRatio", "op": "gt", "threshold": 1},
    {"key": "MaxSpindleTorqueRatio", "op": "gt", "threshold": 1},
    {"key": "MaxSpindlePowerRatio", "op": "gt", "threshold": 1}]}},
  {"kind": "leaf", "name": "Rapid", "when": {"join": "all", "terms": [{"key": "IsRapid", "op": "eq", "threshold": 1}]}},
  {"kind": "leaf", "name": "Air", "when": {"join": "all", "terms": [{"key": "IsTouched", "op": "eq", "threshold": 0}]}},
  {"kind": "leaf", "name": "Cut", "when": null, "valueKey": "MaxSpindlePowerRatio"}]},
 "range": "all", "stepIndex": <Cut's firstStepIndex>}

selectedStep 是 { stepIndex, leafId, leafName, leafValue, values, trace, error }。在 Cut 的第一步上，leafName 是 Cut，leafId 是 histogram 裡 Cut 的 id；trace 依序列出試過的節點，每個是 { id, name, kind, held }——Overload、Rapid 與 Air 為 held: false，最後的 Cut 為 held: true；values 帶著樹所讀的每個鍵在這一步上的值，{ key, value }，其中 IsRapid 為 0、IsTouched 為 1；leafValue 是它的主軸最大功率比；除非有讀取失敗，error 為 null。三個比值在這裡必須是數字。不是數字的值，以字串 "NaN" 傳送：在一個切削的步上三個都是 "NaN"，表示播放在那裡沒有算物理；只有兩個主軸比是 "NaN"，表示專案的主軸能力在那一步的轉速下給不出限制——不論是哪一種，沒有這些值的步都不可能是 Overload，而 Overload 的占比，對那些步的負載什麼也說明不了。改用 Overload 的 firstStepIndex 指名，同一個請求就會顯示是哪一個比值大於 1。

409 StepColorTreePreviewSuperseded 是一次在結束前就被停下的試算：被另一次試算停下——一個執行個體上同時只跑一次試算，不論是誰送的，瀏覽器裡按下的試算也算在內——或被它底下的步的改變停下，例如重置、重新計算步驟物理量、註冊了一個鍵或把一個鍵設成視覺指標，或在步上寫入了值。再送一次；一直回來的 409，表示有別人正在這個執行個體上工作，所以每次重試之間留些時間。反過來也一樣：從這裡送出的試算，會停下某人瀏覽器裡正在跑的試算，他的面板接著會說它的試算被停下了，所以只在需要它的答案時才送試算，絕不在迴圈裡送。stepIndex 指到步序列上沒有步的位置時，回應 400：StepColorTreeNoStep；若是播放接下來要建的那個索引，則是 StepColorTreeStepNotBuiltYet。

占比就是報告，而取得它們既沒有改專案，也沒有改任何畫面。回報每片葉的名稱、步數、秒數與占比，noValue 不是空的時連同那一列，以及上面的證據。Overload 的占比首先是對仿真的一個讀數，其次才是關於程式的發現：在稱它為風險之前，先對照專案的假設檢查它（仿真報告）。只有在樹要留在專案裡、要顯示在畫面上，或要在步檔案裡給它一欄時，才往下做。

5. 加進專案，而且只新增¶

PUT /api/execution/step-color-trees/LoadCheck
Content-Type: application/json
If-None-Match: *

{"key": "LoadCheck", "name": "Load check", "nodes": [
  {"kind": "leaf", "name": "Overload", "hue": 0, "when": {"join": "any", "terms": [
    {"key": "StressRatio", "op": "gt", "threshold": 1},
    {"key": "MaxSpindleTorqueRatio", "op": "gt", "threshold": 1},
    {"key": "MaxSpindlePowerRatio", "op": "gt", "threshold": 1}]}},
  {"kind": "leaf", "name": "Rapid", "when": {"join": "all", "terms": [{"key": "IsRapid", "op": "eq", "threshold": 1}]}},
  {"kind": "leaf", "name": "Air", "when": {"join": "all", "terms": [{"key": "IsTouched", "op": "eq", "threshold": 0}]}},
  {"kind": "leaf", "name": "Cut", "when": null, "valueKey": "MaxSpindlePowerRatio"}]}

回應 200，{ success, item, appearanceOnly, renamedFrom, messages, generation }，表示樹已加入：item.state 是 registered，item.problems 是空的；item.tree 是編好號的樹，編號 1 到 4、nextId 為 5；item.leaves 以 { id, lane, name, shortName, hue, hueAuto, color, valueKey } 給出每片葉，color 是圖表與 3D 畫布替它的步上色所用的 #RRGGBB；appearanceOnly 為 false，renamedFrom 為 null。messages 重述 check 說過的，接著是專案其他步變數與著色樹回報的內容。在 §7 存檔之前，樹只在開啟中專案的記憶體裡。加入它會重新註冊專案的步變數與著色樹，這會停下那一刻正在跑的試算（409），而每個畫面的顏色維持原樣：它們只跟著視覺指標走。

412 StepColorTreeKeyRepeated：專案在這個鍵下已有一棵樹——別的呼叫端的，或你這一趟先前某次嘗試放上、回應卻遺失了的那棵——而什麼都沒有改變。用 GET /api/execution/step-color-trees/LoadCheck 讀它，把它的 item.tree 和 §2 的樹逐個節點比對——名稱、色相、條件、顯示數值鍵；編號是伺服器給的。是同一棵樹：依它的鍵試算，{"key": "LoadCheck", "range": "all"}，然後繼續。是另一棵樹：另選一個鍵，再 PUT 一次。絕不要不帶 If-None-Match 再送一次 PUT：少了它，請求會取代別人放上去的樹。
409 StepColorTreeKeyRepeated：如 message 所說，專案在這個鍵下有一個步變數。另選一個鍵。
400：鍵被拒絕，見 §1 的說明；或本體被拒絕，見 §3。

6. 只在它必須上畫面時：設成視覺指標，然後把舊的設回去¶

這是唯一會改變別人所見內容的一節。視覺指標是專案設定：設定它，會重畫連到這個執行個體的每個畫面上的視覺指標時序圖，以及刀具路徑與切削面的顏色——圖表由上而下分成名為 Overload、Rapid、Air 與 Cut 的四道，執行則換上各片葉的顏色——而存檔會把它存下來。只在要顯示這棵樹時才這麼做，時間也盡量短。

再讀一次視覺指標，GET /api/execution/step-color-trees?lang=en，把它的 inspectingKey（null 也算）保留下來，作為要設回去的鍵——而不是 §1 的那個：§1 之後別的使用者設的鍵，是他們的。接著把這棵樹設成視覺指標：

POST /api/execution/inspecting-key
Content-Type: application/json

{"inspectingKey": "LoadCheck"}

回應是 { success, currentKey, messages }，currentKey 為 LoadCheck。欄位是 inspectingKey，本體裡的其他東西都不讀：{"key": "LoadCheck"} 會清掉視覺指標，卻仍回應 success: true，currentKey: null。

接著主機會在背景填入每一步在視覺指標下的快取值。讀整次執行的圖表，過一會兒再讀，直到 pending 為 false：

GET /api/execution/strip-chart?aspect=Individual&inspectingKey=LoadCheck&xValueCategory=IndexByStep&widthHint=1&dispBegin=0&dispEnd=<count>

items[0].colorTree.leafTotals 就回應所涵蓋的步，每片葉一筆，{ lane, id, steps, seconds }；noValueTotals，{ steps, seconds }，則是不在任何葉裡的步。依 id 對應——清單是依樹的順序排的，所以絕不要以道號當索引——每片葉的 steps 都等於 §4 的 histogram 裡的數字（樹原本就在專案裡時，則是 §5 那次依鍵試算的數字），seconds 也和它們相符。
dispBegin 與 dispEnd 讓回應涵蓋整次執行，而不是畫面上顯示的那段範圍；widthHint=1 讓它只回兩個點，而合計仍計入每一步。
items 是空的而 pending: true，表示 LoadCheck 不是視覺指標：之後有別的使用者設了另一個。就停在這裡，保留他們的。
這樣設成視覺指標的內建樹讀法相同，只有一個例外：physicsShown 為 false 時的 MachiningState。以這個鍵要圖表，回答每次都是 pending: true、items 是空的；POST /api/execution/inspecting-key 回答的則是存下的鍵 MachiningState，和任何被隱藏的物理鍵一樣。讀 GET /api/execution/step-properties 的 currentKey——這時是 MachiningStateGeometry——再以那個鍵要圖表：它那一項的 colorTree 帶著 standsInFor: "MachiningState"，加總是不含物理那棵樹的。

然後把視覺指標設回去，除非這段期間有別人改過它。再讀一次：

GET /api/execution/step-color-trees?lang=en

inspectingKey 仍是 LoadCheck 時，就把設定 LoadCheck 之前保留下來的那個鍵 POST 回去——原本沒有時，就是不加引號的 JSON null——並在 currentKey 等於它時接受：

POST /api/execution/inspecting-key
Content-Type: application/json

{"inspectingKey": "<the key kept before LoadCheck was set>"}

其他任何 inspectingKey，都是 §6 開始之後別的使用者的選擇：保留它。照 §4 的做法再讀一次 GET /api/Execution/status：同樣的 runId、instanceId 與 resetCount，說明合計數的是 §1 的那次執行。

7. 儲存專案，並在步檔案裡給它一欄¶

POST /api/Project/save

回應 200，{ "success": true, "message": "Project saved successfully" }，表示專案檔已寫入，樹也在裡面；409 表示另有一項專案檔作業正在進行，等它結束後再存一次；400 則在 message 裡說明原因，沒有開啟專案也是其中一種。存檔寫出的是開啟中專案的現狀：這棵樹、上次存檔之後對它做的每一項其他修改（別的使用者做的也算），以及那一刻的視覺指標——這就是 §6 要先把視覺指標設回去的原因。從未存檔的樹，在專案重新載入或開啟另一個專案時就不見了。

每一步的資料來自步檔案，也就是執行後作業命令的步驟檔案輸出在播放時寫出的 CSV（寫出執行產出的東西）。它在每個步屬性的鍵下都有一欄，所以樹的那一欄 LoadCheck 帶著每一步的葉編號；GET /api/execution/step-color-trees/LoadCheck 的 item.leaves 把編號換成它那片葉的 name。只有在樹已在專案裡時寫出的檔案才有這一欄，而 §1 的那次執行，是在樹加入之前播放的。要有這一欄，就照重播驗收的播法再播放一次任務——一次重置、一次開始，執行個體上的每個人都看得到——各支程式下方要有一個執行後作業，啟用這個命令（PUT /api/Mission/commands/{path}/enabled，本體為 true），並打開它的步檔案（PUT /api/Mission/commands/{path}/postexecution/enable-write-step-files，本體為 true）；{path} 是命令的項目路徑，寫法見專案建構。啟用命令會執行它底下每一項打開的輸出，而不只是步檔案：先在 GET /api/Mission/list-command/entries 讀它的項目——它的 command 的各個 enable… 欄位說明是哪幾項——並保留它的 isEnabled 與 command.enableWriteStepFiles。兩個 PUT 都在上面的存檔之後改了記憶體裡的任務，所以重播寫出檔案之後，要把兩者都設回原樣，否則下一次存檔——不論是誰存的——會把它們存下來。每個檔案的名稱，見它那一列 StepFile-Create--Start（重播驗收 §4）。一個檔案裝一支程式，而播放每次從別支程式回到那支程式時，寫出器都會重新開啟它的檔案，所以呼叫了別支程式的程式，只留下最後一次呼叫之後的那些列，這時從檔案數出來的數目，就會比 §4 的少。

延伸閱讀¶

透過 HTTP API 進行重播驗收 — 產生並驗收這些步所來自的那次執行，以及步檔案那一欄所需的重播
透過 HTTP 操作著色樹（英文，未鏡像） — 這裡用到的每一條路由、每個欄位與每個回應，樹的形狀，以及共用的視覺指標
透過 HTTP 驅動網頁服務（英文，未鏡像） — 登入、回應封套，以及一個服務只有一個專案
著色樹（英文，未鏡像） — 樹怎麼把步分類、怎麼替它的葉著色
步著色 — 在瀏覽器裡建出並試算同一棵樹
仿真報告 — 占比要放進哪裡，以及一個負載讀數在稱為風險之前需要的檢查