系統在不在跑,畫成一座驛站。數字從外面按時進來,驗過、留下或退回,最後要經過一道人守的門才出得去 —— 每一趟移動都對應稽核紀錄裡真的多出來的一列。滑過任何建築可以看到它在平台上實際是什麼。
潮信塔
卸貨場
0
批 received
驗貨棚
0
批 validated
廢料棚
0
列被拒
糧倉
0
筆 timeseries
訊號塔
0
筆 webhook 事件
編年簿
0
筆 · 近 24 小時
哨站
0
個 LINE 群組
關門
待審 · 等 bot
待築的路
0
件投遞工作
驛站的人
收信員
安靜
守著潮信塔。潮來了就搬,潮不來也不能催。
n8n IMAP 收信工作流。超過 24 小時沒有新信才算異常(D25)。
驗貨師
安靜
在驗貨棚裡逐列看。決定哪一列進倉、哪一列進廢料棚。
kpi.validate_import_batch / promote_import_batch / provision_employees。
訊號員
安靜
塔響了才動。塔不響的時候,他也不知道外面是安靜還是斷了。
LINE webhook 接收。永遠不會被標記為故障 —— 沉默無法區分。
戶籍員
待命
替廣場上的人登記,管地緣與行會的牌子,必要時去關門那裡簽名。
透過維運台操作的人。稽核來源為 hr_web。
郵差
安靜
站在關門邊。路築好之前,他沒有一件差事可以接。
投遞 worker。佇列為空,因為沒有東西建立投遞工作(D33)。
「訊號員」永遠不會被標記為故障 —— webhook 只在有人發話時觸發,安靜的週末和壞掉的端點在資料上完全一樣(CLAUDE.md 7.1)。
近 24 小時
0
筆操作
0
自動流程
0
位操作者
村民每走一趟,都對應右邊一筆紀錄。飄動的微塵與光是場景本身,不依附任何數字。
操作紀錄
這段期間沒有任何操作。
變更理由不在這裡 —— 它是操作者針對具體情況寫的自由文字,逐筆調閱才看得到。
往內陸 —— 聚落
廣場上等登記的那幾個聚落,是這張圖的前排。同樣是 org.organizations 的列, 只是這裡畫得完整。屋頂的數量就是在籍人數 —— 三個屋頂是三個人,不是「小」的裝飾。
這張圖刻意不畫錢。46 個聚落只有一到三個人,而 D07 遮蔽它們的理由正是「一個人的單位合計就是那個人的業績」; 用營收決定房子大小,等於把同一件事用輪廓洩出去。牆外不是這裡 —— 牆外是哨站,是話出去的那一側。