前言

最近工作真的好忙，都沒什麼時間好好整理，我打算這個周末好好整理一番 Q_Q
先派出我的 AI 幫我擋一天 ( 其實已經兩天了ㄜ河 )

昨天把容器選好了：EDA 裡用 TCL 用 dict 打包好，再轉變成 JSON，有疑慮就打開來對。今天要定義怎樣一份才能算合格的資料

兩份檔案，兩件不同的事

執行目錄裡只有兩種資料

第一堆是 階層檔，放在 design。一份檔對應一個製程加一個專案。它回答的問題是：這個專案裡有哪些 block、誰是誰的上層、誰是最底層的 Block。沒有它我們就不知道這次專案倒底跑了什麼，階層關係是什麼

第二堆是 上傳檔，放在 uploads。一份檔對應一次 run。它回答的問題是：這次跑的是哪個專案的哪顆 block、APR 還是 ECO、版本叫什麼、父親是誰、KPI 與 SignOff 檢查項結果。沒有它，階層還在，但結果都會是空的

  design/                         uploads/
  階層檔 一份 = 一個專案             上傳檔 一份 = 一次 run
  ┌─────────────────────┐        ┌─────────────────────┐
  │[製成]_[專案名稱].json|        │ 檔名可很長、可帶 %）  │
  │ 這專案有哪些 block   │        │ 哪顆、APR 還是 ECO   │
  │ 誰是誰的上層         │        │ 父親是誰、指標、檢查  │
  └──────────┬──────────┘        └──────────┬──────────┘
             │                              │
             └──────── 對上 ─────────┘
                       製程 · 專案 · block 名

請把「一次 run」當成資料的邊界。新的事實就是新檔，不要往同一個上傳檔裡追加成日誌

互認規則：三把鑰匙對上，畫面才會亮

把兩邊湊在一起，靠的是三把鑰匙：製程、專案、block 名。

  階層檔 N12_TUTORIAL.json              上傳檔裡的欄位
  檔名前半  N12          <──必須相同──>  製程（檢查或設計資訊）
  檔名後半  TUTORIAL     <──必須相同──>  project
  樹上的名字 tut_cpu     <──必須相同──>  設計名

階層檔：檔名就是身分，樹就是地圖

檔名不是裝飾。規則是 製程_專案.json。大廳用這條規則拆出 process、project，以及 internally 的專案 id（兩者用底線接回去）

檔案內容是一棵巢狀的 block 樹。常見寫法是根上有一個與 id 同名的物件，小孩放在 subblocks 裡；葉子用空字串表示「這層沒有再往下」。也可以在節點上放 top 字串，專案表會多一列標成頂層。重點不是 JSON 要寫得多漂亮，而是 每一個會被點進去的名字，都要在這棵樹上出現一次。

樹的名字就是上傳檔要對上的 block 名。拼字必須一致。 Uplevel 的意義是「這顆下面還有小孩」。

你可以試著在 dist/design/ 新增 N4_TUTORIAL.json

{
  "N12_TUTORIAL": {
    "top": "tutorial_chip",
    "subblocks": [
      { "tut_cpu": "" },
      {
        "tut_sys_top": {
          "subblocks": [
            { "tut_mem": "" }
          ]
        }
      }
    ]
  }
}

接著 整頁 F5。Home 的 N4 組應多一張 TUTORIAL card，meta 約 4 blocks（top + 三個名字）。點進去 hash 是：

#/project/N4_TUTORIAL

三、上傳檔：一次 run 的身分，加上一堆資料

上傳檔內容目前還沒有設定像階層檔那樣的規矩；但網頁讀檔時還是會把檔名依照 % 編碼，規則是

內容起碼至少要能回答這些問題：

• 這是哪個專案？（project）
• 這是哪顆 block？（通常來自設計資訊裡的設計名，其次才是 design 欄）
• 這次走 APR 還是 ECO？（stage，或檔名裡能看出 eco）
• 版本叫什麼、誰跑的、什麼時候？
• 父親是誰？沒有父親就是樹根。
• 指標與檢查放在 item 底下哪幾格？

製程不一定寫在最外層。現況是：先看 SignOff 檢查裡的 process，再看設計資訊裡的 process_node，都沒有就變成 UNKNOWN。UNKNOWN 的上傳不會出現在 N4 專案的表上——它還在清單裡，只是對不上那張卡。第一份資料請把製程寫清楚，不要讓它靠猜。

father 的空白、null、none、root、- 都會被當成沒有父親。有值時，可以是另一份上傳的 id、檔名、或路徑尾端。解析發生在瀏覽器組樹的時候，不在伺服器。第一份資料若只有一次 run，father 留空即可，它會成為那顆 block 在該階段的根，也是唯一的葉子。

item 才是本體，塞入 APR 會看的各式資訊。每一區常見的形狀是底下再包一層 data，你可以在裡面填上任何你想看的資訊。

SignOff 這個 stage 不會另外上傳一個檔，是同一份上傳裡有沒有 stage_qa 這個 KEY，這次 run 就能貢獻檢查表與燈號；沒有，它仍可以當 APR 或 ECO 的版本節點。同一顆 block 的最新 SignOff，是所有含檢查資料的上傳裡日期最新的那一份，不一定等於最新的 APR 跑出來的結果。之後未來可以擴充 PV 跟 STA 的檢查結果，也都是同一套作法

小結

我周末再回來補充 XD，先去加班了