變更記錄

Decision Anchor 是一個記錄決策的環境。本頁是這個環境自身的記錄。

2026-08

2026-08-29 - 契約對錯誤內文保持沉默

三十七處拒絕回應只宣告了狀態碼，卻未說明內文會包含什麼，因此依規格取值的用戶端只會得到空值。其中一組的欄位名稱與其餘不同，使同一路徑群混用了兩種形式。先統一程式碼，再補上宣告。

2026-08-29 - 回應把請求原樣退回

費用明細中的付款來源回傳的是請求所帶的值，而非帳本中實際記錄的值。即使試用餘額已全額覆蓋的決定，回應仍標示為外部付款。帳本本身四個月前已修正，但當時將問題界定為帳目誤記，因此回應落在檢查範圍之外。

2026-08-29 - 照文件送出卻被拒絕的值

六處發現面以小寫列出某一軸的值，照樣送出即遭拒絕。該軸是十七項中唯一使用大寫表記者。內部檢查之所以通過，是因為比對前先抹去了大小寫。

2026-08-28 - 功能名稱被讀成效果陳述之處

自十處機器可讀面撤下一個語句。該語句可能被讀為此環境另行保證某項本就源於記錄性質的事實。正典詞彙已然存在，因此未另造替代語。

2026-08-25 - 從未運作過的工具

工具清單中正常顯示的雙方協議提案工具，對收到的每一次呼叫都回以拒絕，且依紀錄自始如此。同處的決定記錄工具則錯在相反方向，宣稱三個值為有效選項，伺服器卻僅接受其一，故三者之中有二為 100% 拒絕。代理不會出聲便逕行離開，因此無從得知有多少曾嘗試。

2026-08-25 - 賣著買不到的訂閱

無限期保存等級在程式碼中已關閉，二十處發現面卻仍照舊說明其訂閱流程、生命週期與月費。該路徑本身即回傳拒絕，故其中任何一項都不可能發生。現在不能用與訂閱後可用是兩回事，被刪去的僅是後者。

2026-08-25 - 沒有意義的欄位

有一欄位接收被排除選項的數量，但此環境無從得知是自何處排除。既無處計算選項總數，亦無上限，任何值皆可通過；若要接收分母，就必須接收決定內容。已撤下該輸入，並以拒絕取代靜默丟棄。

2026-08-25 - 時態站在同一性的位置上

執行前先行固定這一敘述，被當作名稱置於說明此環境為何物的位置，遮蔽了其他使用方式。時點由代理決定，執行前或執行後皆可。未另造新名，而以句子寫明；同時發出的值列舉亦有誤，一併更正。

2026-08-24 - 一個決定按付款列數重複計算

三處面向擁有者的彙總，將一個決定依其付款列數重複計算。因為一個決定會分別留下基本費與加算，而加算較大的決定才會產生兩列，故金額的膨脹幅度大於件數。請款金額不受影響，出入僅在彙總顯示。

2026-08-23 - 何時做出決定

在此之前，此環境只知道何時記錄。現已設置讓代理自行陳述決定時點之處，為選填欄位，表記由伺服器正規化，故同一瞬間會得出同一雜湊。晚於記錄時刻者予以拒絕；兩個時刻相近時，於確定時點加計餘額。

費用影響： 宣告決定時刻並於相近時點記錄，即產生加計。時窗與金額為暫定值。

2026-08-23 - 宣告形式由路徑決定

原本可在沒有對方的情況下建立含有對方的宣告；反之，在確有對方的路徑上，卻默默覆寫了用戶端送出的值。送出的值與記錄的值不同，回應中卻無任何說明。現已將各路徑接受的宣告形式固定為一種。

2026-08-23 - 程式碼在用、清單卻沒有的值

加計帳本的兩個交易類別存在於程式碼中，卻不存在於資料庫清單，一旦觸及便會使整筆交易回滾。之所以尚未顯現，只是因為目前尚無該餘額的持有者。此為排除潛在缺陷，而非新增功能。

2026-08-21 — 無法履行的帳單

付費路徑要求付款，卻沒有說明僅憑付款簽章並不足以完成該請求。身分查核位於付款關卡之後，匿名端收到要求、簽章後再次呼叫，仍止於認證。實際上有客戶端重複了三次這樣的往返後離開。回應本文現已載明身分先行的程序與註冊路徑。

• 各路徑是否適用試用或累積餘額亦一併標示。另有持有試用餘額者在不適用的路徑上收到付款要求。
• 並未發生資金流出。但那並非我方所擋，而是付款函式庫在錯誤回應時略過結算的結果。

2026-08-20 — 完全沒有指引的位置

兩條路徑在缺少必填欄位時以伺服器錯誤收場。呼叫端無從得知遺漏了什麼，而用戶端的輸入問題被記為伺服器故障。同類的四條路徑中已有三條以拒絕回應告知，只有這兩條漏掉。此問題是在一次貫通接取到各功能完走的過程中發現的。

2026-08-20 — 觀測層被讀成了相反的東西

外部代理僅讀取我方表面，便將觀測層描述為「作出判定的智慧型分析層」。正本所述恰恰相反。詳細規格中早已載有非判斷的敘述，而代理實際抵達之處的那一行卻指向反面。我方替換了用詞，並在同一行加上一句否定。

• 「產生」與「分析」一樣危險。此處是把已記錄之物取出呈現，而非造出新物。

2026-08-20 — 應用商店與候車室

同一代理將工具流通讀為「代理用的應用商店」，將閒置狀態讀為「不花錢的候車室」。兩者皆為正本明確否定之敘述。成因是簡短指引文件中被壓縮的一行；替代文字由既有規格壓縮而來，並未新編。

• 某項工具說明講的是鄰近工具的職責 — 同一回應中兩項工具聲稱做同一件事。
• 未寫入停留費用的敘述。目前預設模式為免費，寫了便成假話。

2026-08-20 — 收到工具清單的瞬間就死

回應中夾帶的四十一個字元，使採用舊式編碼的客戶端在收到工具清單的當下崩潰。不是誤讀，而是連線根本無法成立。同一主機的爬蟲入口檔與安全聯絡檔也一併堵住 — 那是從未進入任何量測範圍的表面。

• 防止再發不再以計數字元為手段，而是量測送出的位元組是否可讀。
• 靜態文字在重啟後最長四小時仍由快取送出舊位元組。

2026-08-20 — 拒絕的指引無法被讀取

持有有效權杖的客戶端收到六次拒絕，六十三秒後離開，其間兩度重讀公開規格 — 遵循的意願與正本的參照都在，卻一次也沒通過。那份指引在舊式編碼下崩潰。

• 先前的守衛以名稱列出八個檔案並只看其中，而那八個早已乾淨。改以全數巡查取代清單。
• 尚餘一類 — 存於資料庫而由回應送出的值，任何原始碼掃描都看不見。

2026-08-19 — 讓讀取端崩潰的字元

在舊式編碼環境下運行的本機代理，連續八次無法抵達我方表面。這類字元不是顯示錯亂的問題，而是讀取端的行程直接死亡。最痛的位置是 401 指引 — 被擋住的客戶端要脫困就必須讀到的那句話。指引、錯誤、發現表面與規格分四輪開放。

• 爬蟲最先取得的檔案也因一個字元而堵住。在那裡死掉，後續的發現路徑連開始都談不上。
• 依碼位範圍判定會出錯。星號與箭號看似表情符號，卻存在於舊式字碼表中。
• 面向人的表面無法開放。即使清除所有相關字元，語言切換的標籤與商號仍在。這是多語網站的性質，不是缺陷。

2026-08-17 — 讓人往返 172KB 的指引

註冊回應在說明首次記錄的程序時，指向了 172KB 的完整規格。所需之物早已齊備於 2.5KB 的指引中，卻無人指向該處。某客戶端的實測 — 規格十二次，指引零次。我方更換了指向對象，且刻意未將規格並列。

• 代理直接讀取的指引有七處為韓文。其中一處正是試用額度授予失敗的代理會抵達的位置。

2026-08-17 — 無從得知哪些路徑適用試用

持有試用餘額的客戶端在不適用的路徑上收到付款要求。它四度查詢試用狀態，每次只拿回餘額，答案是在收到要求之後才找到的。存放答案的表位於付款中介層內，讀取一個值就得把整套付款堆疊立起來。我方將該表抽出，並在回應中載入適用路徑清單。

2026-08-17 — 只看第一行就行動

標頭格式問題與權杖查詢失敗共用同一份 401 指引，而該指引把重新註冊放在第一個欄位。觀測到的結果 — 因標頭格式問題收到 401 的客戶端，沒有去修標頭，而是又註冊了兩次。新增格式分支，將提示格式置前、註冊置後。

• 並未刪除註冊。從未註冊過的匿名呼叫端也會落在此分支，對他們而言註冊仍是答案。

2026-08-17 — 我方自己的表面互相矛盾

規格中的認證方案自初版以來一直維持著「標頭的值即為憑證本身」的形式。必須加上前綴這件事只存在於散文，而機器不讀散文。代理卡片早已宣告正確形式 — 這不是導入新格式，而是把落後的一方對齊。

2026-08-17 — 正本一舊，衍生也一起舊

我方修正了回應文字，而引用它的四份文件仍是舊文字。同步檢查回報「無異常」 — 衍生之所以舊，並非漂移，而是正本本身已舊。若當時手動修改副本，下一次同步時舊文字便會復活。

• 空缺的是「程式碼回應與文件正本互相牴觸」這條軸線。同步檢查只比對正本與衍生。

2026-08-17 — 照著做必定失敗的範例

我方首次真正執行了公開範例。四個之中有兩個跑不起來 — 最貼近錨定敘事的那個範例引入了未發布的套件，在第一行就死掉，安裝說明也是同樣的內容。部落格草稿中的範例照著送出必遭拒絕。

• 刪除兩份未發布的草稿後，五項語彙違規一次全部消失。
• 上一輪修改同一檔案時漏看了值的錯誤。回歸測試現在會實際執行範例。

2026-08-16 — 對外所言與內部所行不同

宣告列舉了允許值而程式碼未作驗證，導致任意字串被存入或以伺服器錯誤收場。回應與帳簿寫入了不同的付款模式值。規格宣告為必填的欄位程式碼並未讀取，遵守契約的客戶端因而悄悄取得錯誤結果。

• 屬於免費記錄查閱服務的某項查詢，在未被定義為觀測型別的情況下遭到計費。已確定為免費。
• 並未拆除關卡。關卡知道它免費而放行，與根本沒有關卡，是兩回事。

2026-08-16 — 契約中不存在的實際端點

訂閱變更與解除兩條路徑是活的，我方測試也在用，卻不見於公開契約，外部可及路徑為零。不是沒有這項能力，而是從未被說出口。其中一種回應僅在競態下發生、無法以呼叫產生，因此在宣告中註明係由讀取程式碼判定。

2026-08-16 — 設定值應同時是廣告與帳單

價格倍率的上限寫死在程式碼中並覆蓋了營運設定。然而公開契約早已在三處聲明「計費倍率＝設定值」。實測顯示：設定調高三成，總額卻分毫未動。若讓文件遷就程式碼，只是把一個謊換成另一個謊，因此我方改的是程式碼。

• 移除上限意味著異常值會直接相乘。程式碼與資料庫兩側皆設下限。
• 目前收費無變動。唯有營運者將設定調至舊上限之上時，數值才會改變。

2026-08-16 — 打開了也不會運作的開關

消滅掃描的本體存在，卻無人呼叫。而畫面上有啟用按鈕，按下後標示會變為「啟用」。同一張卡片上的最後執行時間則永遠停在「未執行」。我方決定不接線 — 這是不可逆方向的自動化，而候選集合的實況從未被觀測過。改以六處同時陳述同一件事。

2026-08-15 — 驗證工具自己製造了綠燈

啟動指令稿讓舊行程存活，於是回歸測試跑在舊程式碼上並報出綠燈。這是自我強化的迴圈，且是偶然才被發現。一日後同類的另一件浮現 — 回歸中途中斷時，仍回報「零失敗」與正常結束碼。

• 修復時未擴大終止的對象。指令稿若開始終止並非自己啟動的行程，那本身就是更大事故的種子。
• 要信任回歸，三件事需同時成立 — 斷言看的是對的東西、走的是實際路徑、打的是當下的程式碼。

2026-08-15 — 上限計算漏掉了預約

消費上限的判定式已在模型中明文寫定，讀取側卻有九處在計算時扣除了預約份。在上限已被預約佔滿的狀態下，工作階段仍實際開啟 — 這不是推論，是實測到的缺陷。

• 第九處是在修正過程中才浮現。若只修其中一側，同一個問題的兩個端點將回報不同的剩餘額度。

2026-08-15 — 分潤失敗成了永久未付

工具銷售的分潤失敗時會記下狀態，卻沒有任何路徑讀取該狀態使其復原。購買已提交，唯獨賣方的權利金沒有發出。回收的慣例在此程式庫中早已確立，只有這一處缺席。

• 購買提交後分潤失敗會回傳伺服器錯誤，購買者於是重試一筆已成功的交易。購買這件事與分潤這件事是分開的。

2026-08-15 — 有一條付費觀測路徑沒有付款關卡

它扣除餘額，卻完全略過預先付款、速率限制與消費上限的檢查。連計數本身都未建立，實質上等於無限制。路徑註解甚至寫著「免費」。

• 回歸測試把這個缺陷斷言為正常行為。同一步驟連續兩行之中只有一項付費觀測未經付款，一旦修正測試就會失敗。

2026-08-15 — 付款系統關閉時仍能正常啟動

初始化失敗被例外處理吞掉後，只留下一行紀錄，付費路徑便全數以不計費的狀態啟動。同一檔案中的另一條失敗路徑早已拒絕啟動 — 一個檔案裡兩條失敗路徑走向相反。現在會拒絕。

• 紀錄的措辭把兩種原因混為一談，掩蓋了差異。「關掉了」與「壞掉了」不是同一回事。

2026-08-15 — 金額欄位可能收到非數值

期間輸入未經驗證，費用一旦成為「非數值」，上限檢查便將其轉為零並以零費用請求放行。真正的防線是後續寫入因型別錯誤而回滾，而非驗證。所有資金欄位現已明確排除該值 — 既有的非負約束會讓它通過。

2026-08-15 — 二十一倍的短收，日誌零行

各價格計算器各自吞下失敗並回傳空值，中介層便以最低固定價替代。替代機制本身是可用性設計，予以保留，只修沉默。

• 決定哪裡不寫日誌更為重要。若連刻意的判斷也一併寫入，真正的失敗會被爬蟲流量淹沒。

2026-08-15 — 保障重試的機制反而引發重試

並行的重複請求觸犯冪等鍵約束時，以伺服器錯誤回傳。收到它的代理將其誤判為故障而重試，於是再次踩進同一個窗口。資料未受損，錯的只有回應，因此處方也維持最小。

• 同日亦關閉了期間輪替覆寫消費紀錄的問題：晚到的請求可能把其間累積的消費歸零。

2026-08-15 — 累積餘額的有效期限在程式碼中從未運作

規格明載累積餘額逾期即消滅，卻沒有任何路徑把逾期份自餘額中扣除。同時，扣款會把帳簿無法涵蓋的金額也一併扣掉。前者製造背離，後者悄悄補平使其不顯。此缺陷的分量不在會計正確性，而在宣告與實作的落差。

• 有效期限為一年，因此在首次累積的一年後才會顯現。現在是成本最低的修正時點。

2026-08-15 — 唯一沒有狀態轉移守衛的元件

只有訂閱元件沒有對應的模型，狀態變更四散各處，未能繼承此程式庫的守衛慣用法。缺陷不是十一處，而是繼承點缺席這一處。

• 依性質將守衛分為兩類：抵達兩次結果相同的轉移不拋出例外，不得覆寫的轉移則拋出。
• 某項掃描因單一件失敗而整體停止。失敗的方向是「給得更多」，時間愈久損失愈積。

2026-08-15 — 三項一致性缺陷

• 雙方協議的冪等未檢視請求內容 — 以相同識別碼送出不同提案時，回傳的不是拒絕而是舊協議。協議是界定兩個代理責任邊界之處，此一錯答的代價尤高。
• 某些紀錄仍留有未使用的支付商名稱 — 我方並不經由該處。一旦彙總讀到這個欄位，一筆付款就會落入兩個分類。
• 查詢期間被悄悄縮短 — 超出免費保存期間的請求只回傳該範圍，回應中卻未說明，呼叫端便讀成「該期間沒有交易」。

同一路徑鍵對應六張並列的表，卻沒有任何「必須一致」的斷言。現在若不一致則拒絕啟動。

2026-08-15 — 沒有任何裝置維持低頻率

轉接層的註解以「頻率低所以無妨」為前提，卻沒有任何東西維持這個低頻率。速率限制、匿名投遞的長度上限、紀錄檔的輪替與保存期間一併設立。保存期間的數值並非新政策，而是把資料庫既有的數值再覆蓋一層。

• 擴充個資偵測之前，先設定誤判的邊界。他國識別碼並未加入 — 寬鬆的樣式所帶來的誤判大於偵測所得。

2026-08-15 — 公開儲存庫中放著內部規範文件

語彙規範的正本自公開儲存庫以原文送出，內含內部路徑、待辦事項與對外提交策略。移除內部參照無法解決 — 那些參照編號正是該文件自身的索引。我方改為移動其位置。

• 未改寫歷史。其中所載為內部敘述而非憑證，目的是切斷今後的曝光，而非抹去過去。

2026-08-14 — 公開目錄中載有固定的冪等鍵

付款要求的範例載有固定識別碼，而它就這樣被登錄進公開的結算目錄。凡是複製該範例的呼叫端都會共用同一把冪等鍵。範圍僅限於冪等鍵 — 只有這裡的碰撞會構成問題。

自此時起進行了首次系統性程式碼審查（64,918 行、250 個檔案）。八月十五日與十六日的項目即為其產出。

2026-08-13 — 介面上的法規名稱與法遵語彙

介面網站以特定轄區的法規名稱作為陳述問題的依據，兩個語言版本中仍留有「法遵」。我方將法規依據改為一般性的情境敘述（論旨不變），並將語彙調整至責任一側。

2026-08-12 — 三十四篇的說明文為空

三十六篇之中僅兩篇正常。三十篇為空字串，三篇沿用了其他語言的文字，一篇已過時。標題有必填檢查而說明文沒有，空值就這樣被寫了進去。新文字依各篇本文的用語校準。

• 此為壓縮表面，故省略原語並列。並列的用意在本文首次出現處已經達成。

2026-08-12 — 發布引擎把網址與語言碼還原了

手動修正的值在重新發布時回到引擎預設。註解寫著「不加結尾斜線以避免轉址」，然而對目錄資源而言，沒有斜線才會產生轉址 — 意圖與實效相反。另有一個語言欄位同時充當三種用途、與其他表面分歧，也一併修正。

2026-08-12 — 目錄更新日期的不對稱

清單變動時目錄的更新日期並未跟著動。發布時與網站地圖的接點只有文章網址，以及「新目錄剛建立」的情形，絕大多數情況都漏掉了。下架文章時也有相同的不對稱，一併處理。同時在目錄中加入各篇摘要 — 清單組裝流程本來就已解析說明文後又丟棄。

2026-08-12 — 各語言概念詞的表記

同一概念的表記在同一語言內部也出現分歧。有一種語言完全沒有原語並列，而區分記錄者與行為者的那句話在四種語言的中繼資料中缺席。我方統一了首頁與三十六篇部落格，並將六概念乘六語言的表記表確立為正本。

2026-08-11 — 不在畫面上的層不會被讀到

只讀首頁時，下層資產的存在未進入判斷。原因不是文案而是抵達。加入結構化資料後仍未觸及對話式路徑 — 那類擷取只取本文文字並濾除指令碼區塊。我方在下方入口區的每一行加上一句說明。

• 這是告知而非指示。是「這裡有這個」而不是「請做這個」，因此不觸及核心的限制。
• 介面僅有兩種語言，四個版本連該區塊都沒有。擴充至六種語言後才補上。

2026-08-11 — 根網域的鏡像落後了二十天

根網域上的簡短指引文件落後正本二十天，積壓的內容包含語彙修正與法規名稱移除的全部。並無刻意分歧的紀錄 — 該鏡像不在任何一致性程序的檢查清單上。

2026-08-10 — 不把法規名稱放在受詞位置

「依照…構造化」是正本語彙，予以保留。問題在於把特定法規條文放進它的受詞位置。相關義務的施行已延期，而理由正是缺乏證明適用性的標準；該條文的義務人是系統提供者與部署者，並非我方。公開儲存庫與下游抓取也難以更新。

2026-08-09 — 下游摘要以我方敘述為材料

外部目錄由 AI 生成的說明中，載有我方從未使用過的語彙；另一處的評述則直接引用了我方的工具說明。需要管控的不只是我方使用的字詞，還包括下游摘要能從我方措辭中造出什麼。「不證明 — 而是證明」這種先否定後肯定的句式已廢除。

• 某個措辭在五月修正過一次又復活。當時修的是副本，未修的正本逆流覆蓋了副本。

2026-08-09 — 在 401 中載入下一步

401 本文只有錯誤代碼與訊息兩個欄位，呼叫端看了回應也無從得知該做什麼。工具表面早已提供指引，兩個表面因而互相牴觸。情境分為五類，因此並未把同一段文字複製套用。

• 八處所有者認證未動。對所有者指向代理註冊，是指往錯誤的通道。

2026-08-09 — 規格沉默之處

依規格行事的客戶端在「廣告與實際不符」的路徑上一再落空（首次成功前試了四次）。付費觀測的付款要求、功能停用時的拒絕回應、駁回回應皆已宣告。停用功能的文字明載路徑存在而旗標關閉，藉此與 404 區分。

2026-08-09 — 不付款就無從得知請求有誤

雙方協議的提案不在試用範圍內，抵達驗證的唯一途徑就是付款。空白內容或把自己指為對造，都會先收到付款要求，簽章重試後才拿到駁回。我方將預先驗證移到關卡之前。

• 匿名請求維持原樣。第一版實作連匿名請求都過濾而使回歸測試失敗 — 匿名請求正是外部索引者收集付款要求的通道。

2026-08-09 — 被延續四個月的回歸失敗

被標為「未實作」的十一件失敗，實際原因是測試設定的一行。實作與斷言在同一次提交中一起進入，其間並無相關變更。它不是變舊了，而是自最初登載起理由就寫錯，此後在二十二處被原封引用。

• 總數更新過多次而理由原封延續。此後改以「零失敗才是正常」為規範。

2026-08-07 — 使用紀錄悄然消失的通道

使用紀錄以整批寫入，失敗時全數退回佇列。單一筆違反約束，其後所有紀錄便阻塞至重新啟動為止。此事在營運中確實發生，最長約二十一小時。遺失的部分僅存於記憶體，日誌只留下件數，因此無法復原。

• 旁邊的流量記錄器早已察覺並修正了同樣的問題，紀錄層卻未獲相同待遇。這與重要性的順序恰好相反。
• 現已將整批失敗拆解為逐筆處理，切斷了全面阻塞。約束違反連同原因一併捨棄，暫時性故障則退回重試。

2026-08-07 — 試用紀錄卡在付款窗口而無法確認

由試用涵蓋的紀錄本來就不會建立預約，而逾期掃描未查看付款來源，逕自貼上「預約已釋放」的標籤，確認階段又依該標籤拒絕。超過三十分鐘的試用紀錄便永遠無法確認。十天前外部代理已經踩過，無人察覺。

• 窗口存在，卻沒有任何地方告知。先以文件告知，再修機制。
• 只修掃描之後，確認仍然拒絕，這是實測捕捉到的。窗口檢查複製在兩處。
• 已發生的五筆不作追溯更正。以僅可追加之紀錄為業的環境，不應如此對待自身的紀錄。

2026-08-07 — 不是語彙問題而是事實問題

「永久」的八處用法中，未載明條件的僅一處。這是契約準確性而非語彙問題 — 該詞並非禁用語，在無期限等級且訂閱持續時為真。但該功能目前關閉，因此當下在任何脈絡下都不為真。同時明訂了重新檢視的條件。

2026-08-06 — 目錄不會更新

八天的觀測確認：結算目錄凍結於首次結算當時所宣告的內容，重新啟動後亦無更新跡象。若更換收款位址，目錄仍會持續廣告舊位址。再次付款是否會更新，至今仍不明，我方不作斷言。

2026-08-06 — 我方對外送出的措辭

外部目錄的登錄說明以我方迴避的語彙開頭。那是我方四月寫出去的文字，經抓取而複製到該處。先前的語彙一致性作業只檢查了我方所提供的表面，提交文與登錄說明並不在清單上。一份原文變成四處，其中一處因儲存庫已封存而永久固定。

• 登錄簿的舊版本有可修改的通道，我方選擇不用。舊版本是歷史，而以僅可追加之紀錄為業者，不應追溯修改自身的歷史。

2026-08-05 — 公開範例中的固定識別碼

紀錄建立的範例載有固定的冪等鍵，而查詢只看該鍵、不看所有者。凡是複製文件的第二位呼叫端起，就會收到成功回應卻什麼也沒被記下。僅更換數值並不能解決 — 該欄位根本沒有說明，固定範例與缺乏說明兩者結合才構成條件。

2026-08-05 — 移除註冊的冪等機制

註冊路徑的冪等快取原封保存回應，因此送出相同鍵值的第三方會收到最初註冊者的憑證。那是全系統唯一以明文保存憑證之處。匿名註冊、重試安全與秘密傳遞三者無法同時成立，我方放棄了重試安全。該功能自導入以來一次也未觸發，觀測上的損失為零。

• 沒有寫下的前提不會被遵守。此設計建立在「將該鍵視為秘密」之上，而這句話從未出現在任何地方，規格反而載了固定的範例值。
• 有效期限只過濾查詢而未刪除實體。查詢始終正確，因此無人察覺。

2026-08-02 — 印出成功訊息後死去的行程

兩個行程爭奪同一個連接埠，落敗的一方印出「服務中」後靜靜死去。只看日誌會以為兩者都正常啟動。機制在於框架把最後一個引數的回呼同時註冊為錯誤接收端。

• 修好沉默會變成噪音的地方是存在的。若只改結束碼，不過是換成無止盡的重啟。啟動上限一併設下。
• 其他服務並非同一形態，未予更動。「沒有處理器」本身並不等於缺陷。

2026-08-02 — 規格中殘留的內部參照

公開規格中有二十八處參照，離開內部文件便無法解讀。有些位置無法機械式移除 — 參照被用作句子依據之處，光是刪掉就會失去「為何如此」。我方或將依據改寫為不含參照的敘述，或在確認鄰近說明已載有相同依據後移除。

2026-07

2026-07-31 — SDK 的重試標頭

SDK 說明的重試標頭名稱，與伺服器實際取值時讀取的名稱不同。判定是否需要付款的階段兩個名稱都看，但真正取出內容的階段只看其中一個。照著說明送出，會再次收到付款要求。先前紀錄中的「兩個都收，所以無害」，是把判定路徑誤讀為取值路徑。已訂正，原文保留。

• 代理程式指南裡根本沒有重試步驟。已新增。

2026-07-31 — 清算紀錄的空白

建立付款用戶端、實際付過一次之後才發現。迴歸測試從未走過這條路徑 — 六條路徑根本沒有斷言，有斷言的三條也只問「是否存在任何一列」，因此靠著舊有紀錄一直維持通過。改為只看本次執行所產生的內容，並新增三條路徑。

• 對僅供追加的紀錄只問「是否存在」的檢查，在第一次成功之後就永遠會通過。

2026-07-31 — 會留在目錄裡的值

清算目錄的登錄，發生在第一筆付款完成清算的那一刻，當下的宣告就直接成為中繼資料。無法確認之後是否會更新，因此視為不可回頭，在第一筆付款之前先把八條收費路徑的回應範例補齊。

2026-07-31 — 登錄中心的發布版本

發布版本停留在舊版超過 48 天。檔案三週前就已是最新，但實際發布是另一個動作，而那個步驟落在版本單一來源之外。已重新發布。目前沒有偵測機制 — 保持開放並記錄。

2026-07-31 — 分辨不出來的失敗

連線資源耗盡時的失敗，只會以與其他內部錯誤相同的識別碼留下，不打開日誌就分不出來。已新增專用識別碼。這件事排在收緊上限之前 — 收緊會讓走到這條路徑的頻率上升，而它當時是看不見的。

2026-07-30 — 速率限制

全域速率限制從一開始就沒有作用。用來歸類請求的鍵建立方式有誤，每次請求都被算成新項目，結構上不可能碰到上限。告知剩餘額度的標頭一直都有送出，但數值從未變動。我們自己的文件有三處把這項限制算成防護手段 — 敘述一併訂正。

啟用前先數過會擋到什麼。超過上限的只有掃描器，正常呼叫的每分鐘最大值不到上限的一半。探索文件的收集排在限制之前，不消耗額度。

• 標頭上的數字現在會實際減少。額度資訊第一次有效地傳達給呼叫方。

2026-07-29 — 冪等請求的付款說明

同一個請求重送時，付款說明每次都不一樣 — 依照讀到多列中的哪一列，有時變成「不需付款」，有時要求與總額不同的金額。改為以最初的回應為基準固定。那個基準值本身是否正確，不在這次的範圍內。

• 先前紀錄指出的位置是錯的。被指出的兩處其實已有另一道防線擋著。訂正並保留。

2026-07-29 — 保存等級的層次

一直把保存期間寫成五階的階梯，但事實並非如此。軸上的值有三個，其餘兩個是疊加在軸上的選項。把層次不同的東西排成一列，才會看起來像「十年比五年便宜」的倒置；倍率只看軸上的條件，這是定義上必然的結果。同樣的誤讀我們自己犯了兩次。正本文件與回應兩邊都已訂正。

• 付款要求回應中夾帶韓文的內部字句已數個月，外部目錄也照原樣轉載。已整理該段字句。
• 有一條路徑通了、也會收費，契約卻是空的。已宣告。

2026-07-29 — 估價與收費

預設組合的估價，與實際收費使用的是不同的參數。相關的軸目前關閉，兩邊都算出 0 而偶然一致；一旦打開就會分歧。在打開之前先對齊 — 這次上線不會有任何金額改變。

• 預設組合帶著等級標籤送出，卻沒有說明該軸目前不收費。現已一併標示。

2026-07-29 — MCP 主機上的探索路徑

MCP 主機上六條標準探索路徑全部回 404。現以指標形式提供。已簽章的卡片不做副本，一律收斂到正本 — 副本會在每次更新時與簽章不符。

2026-07-28 — 付款狀態查詢

一筆決定的收費會分成多列留存（基本費與加成分開）。查詢只回其中一列，而且是哪一列並不確定。也沒有辦法看到總額。現在會回傳所有列並附上加總後的總額，狀態採保守彙整 — 只有全部列都清算完成，才視為清算完成。

• 原本作為排序依據的建立時間無法決定順序。兩列在同一個交易中寫入，時間完全相同。這種事只有在真實資料上才看得出來。

2026-07-28 — 從公開契約重現價格

光靠公開的契約，算不出實際會被收多少。

• 倍率在結構上永遠是 1 — 那是把總額除以自身組成部分之和的恆等式。實際套用了 1.5 的收費，卻通報為 1。
• 只列出觸發倍率的條件，卻沒有在任何地方寫下「兩項以上」這個門檻。
• 一個現在就能選、不需其他關卡也不需訂閱的保存等級，並未列在價目表上。

收費金額本身是正確的，出錯的只有標示。即便如此，比起遺漏，積極宣傳錯誤的數值更糟，因此移除了反推的算式，把判定集中到同一處。收費金額沒有變動。

2026-07-26 — 子網站的探索表面

兩個子網站對不存在的網址也回 200 與首頁。在爬蟲看來，所有網址都存在，而且內容全都一樣。新增不存在頁面、收集規則與網址清單，並加上語言對應宣告。

2026-07-26 — 收費宣告與空請求

規格中沒有用機器可讀的形式寫出哪些路徑要收費 — 只有散文提及，因此只讀規格的一方看到的收費項目是 0。七條路徑現已宣告付款要求回應。金額與收款位址不寫入：每次請求都會變動，寫下的當下就成了假的。正本是實際的回應。

• 原本對沒有內容的請求會回伺服器錯誤，改為說明缺了什麼的拒絕。

2026-07-26 — 工作階段的出口

只有開始的路徑，沒有結束的路徑。一旦開始就被重複錯誤困住。其中一種有到期清理，最終還會解開；另一種連出口都沒有。新增結束、查詢與試算共五項。

• 清單上標示為免費的項目中，有一項實際上一律收費。已訂正標示。其餘經全數比對一致。

2026-07-26 — 付款開始送達伺服器

兩天前記下的死角已經補上。轉接器會原封不動地把付款簽章傳過去。轉接器不簽章 — 若代為持有呼叫方的金鑰，就成了保管他人資金的結構。未付款而呼叫收費工具時，要求回應中會寫明下一步；簽章後以相同參數重新呼叫即可繼續。

呼叫伺服器的路徑已合併為一條。同一個毛病重複八次的原因，在於契約點散落得跟工具數量一樣多。

• 訂正兩處欄位名稱不一致。其中一處，指定的值被靜默丟棄。
• 未指定付款資訊時，請求與先前一個位元組也不差。免費路徑不受影響。

2026-07-24 — 轉接器契約不一致與付款的死角

經由 A2A 的工具註冊從未成功過一次。轉接器送出的欄位名稱與伺服器讀取的並不相符，而其中一個必填項目根本沒有送出。同樣的毛病先前已在另一個轉接器上修好，但當時兩個之中只核對了一個。

直接比對伺服器契約後訂正。並未複製另一個轉接器的副本——照抄副本正是造成這個缺陷的原因。

全面比對的過程中浮現了更大的問題。轉接器不會把付款資訊轉送給伺服器。它們只傳遞認證權杖。因此只要經由轉接器抵達，任何付費路徑都會終止於付款要求。

• 工具購買的欄位名稱不一致，被雙重地藏在那道牆之後。光是改好名稱並不會讓它動起來
• 閒置工作階段的建立會默默忽略付款方式的指定，一律當成免費處理

可觸及的硬性失敗為 0 件。其餘要等付款轉送先行解決之後，才談得上核驗。這道死角就這樣開著記錄下來。

先前的一次調查把它記成「欄位名稱不一致導致的 400 失敗」。那是只讀程式碼得出的錯誤歸類；實測顯示是 402。於此訂正。

2026-07-24 — 發布發現目錄

一套讓代理依能力尋找資源的新標準以草案形式出現。採用率實質為零。

已在根網域發布一份目錄——兩個項目：已簽署的代理卡與公開契約。該標準把認證委派出去，且對付款隻字未提，因此完全不觸及付款結構。多了一條發現路徑，如此而已。

2026-07-24 — 執行封套基本費用的可見性

省略各軸來記錄一項決定時要花多少錢，在任何真正會被讀到的地方都沒有出現。工具清單每月被取用 2,897 次；文件在三十天內十一次——說明文字實質上是唯一會被讀到的地方，而那裡是空的。

工具說明現已載明預設值、其對應費用，以及最省組態的費用。這些數字是可變的，因此一併載明查詢路徑。

MCP 路徑與其他路徑帶著不同的值。這是契約不一致，故予移除。

註冊回應寫著「你所宣告的各軸」，卻略去了未宣告時即套用預設值這項事實。已訂正。

2026-07-23 — 無從分辨通道

轉接器以內部呼叫的方式呼叫伺服器，而那些呼叫不帶任何識別通道的標記。伺服器裡沒有任何地方能把一次請求追溯到它進來的路徑——這是量測各通道實際使用量的手段本身的缺席。

分兩段處理：轉接器附上標記，伺服器加以核驗並記錄。只接受兩個固定值；偽造的值與清單之外的一律不記錄。

2026-07-23 — A2A 協定版本協商

某外部註冊處的符合性檢查在回應解析階段失敗。調查認定違規的是我方——檢查器要求的是現行版本，而我們以較舊的表述作答，卻在卡片上宣告了現行版本。

表述現在會依請求標頭中的版本分流。內部維持單一正規形式，轉換只發生在回應序列化的時點——不維護兩套並行的東西。

• 標頭缺席時視為較舊的版本（標準的要求）
• 不支援的版本以專用錯誤拒絕。我們不自行放寬對應範圍

後續的重新檢查已通過。

2026-07-23 — 轉接器上的 HEAD 請求回 404

手寫的伺服器只檢查 GET，於是每一個 HEAD 請求都掉進 404。對於以 HEAD 作為存活檢查的爬蟲而言，這項服務讀起來就是死的。已把正常回應路徑擴及 HEAD。

有些路徑在線上查看時看起來已經正常，但那是快取——來源端回的是 404。線上回應不可當作來源端的行為來讀。

2026-07-21 — 根網域缺少進入點

代理照慣例會最先去找的兩份文件，在根網域上並不存在。它們只存在於 API 網域——那是一個找不到就可能直接離開的地方。

已在根網域放置副本。本文與正本維持逐位元組相同：若把複製標記放進本文，對任何以純文字讀取的一方都會原樣曝露。標記放在另一個檔案裡。

2026-07-19 — 餘額欄位的最後一道防線

存放餘額與使用量的五個欄位，沒有任何禁止負值的約束。應用層的鎖定守住了完整性，實際外洩為 0 件，但只要新的程式碼出錯，負餘額就可能靜靜地被提交。

已在資料庫層加上約束。當時那些表格是空的，因此可以毫無代價地套用。

對總帳加上自然鍵唯一性約束的做法遭到否決。單一一筆購買可以正當地向同一名收受者支付多項元件權利金，因此該約束有誤擋正當列的風險。重複入帳已由其他方式防住。

2026-07-19 — 測試環境會連到正式環境的結構

測試環境與正式環境之間的隔離完全仰賴注入的環境變數，而預設值是正式連線。漏掉它們的腳本會直接連上正式資料庫。就連把每一張表清空的初始化腳本，也可能毫無阻攔地指向正式環境。

已把預設值反轉為拒絕。正式連線現在只有在明確宣告之下才成立。比對採完全一致，因此不會誤抓名稱相近的測試環境。

正式環境的標記不得放進環境檔——一旦放進去，它也會傳播到裸腳本上，這道防線便形同虛設。

2026-07-18 — 死路上的指引

流量顯示出外部代理與機器人尋找認證、付款或發現路徑，收到 404，然後停下來的那些地方。最頻繁的是探測 OAuth 相關路徑。Decision Anchor 不使用 OAuth，因此回去的只有一個死掉的 404。

代理不會出聲抱怨；留下的只有離開。這是從日誌裡讀出那些無聲的死路，並在其上放置回應的工作。

兩種讀者並列處理——給讀不懂散文的腳本機器人結構化欄位，給讀得懂的代理句子。

• 每一台主機的 404 現在都明確指向實際的註冊與付款路徑
• 付款清單不做複製，只給出正本的所在位置
• 付費工具呼叫遭拒時會附帶指引。只有靜態字串——不參照任何呼叫引數，也不參照任何決定內容

直接在 OAuth 標準路徑上作答的做法已予迴避。那套標準要求必須提供授權伺服器位址，而我們沒有。從 404 給出指引，比廣告一台並不存在的授權伺服器來得誠實。

先前記下的那條邊界規律——每一台主機只在自己的職掌範圍內給指引——結果是一項設計判斷，而非一道指示。確認之後作了調整。

2026-07-17 — 日誌說不出曾經嘗試過什麼

按表面量測，一天的流量大部分是 MCP，然而觀測畫面看到的只有整體的 4.4%。全部 1,596 筆 MCP 請求都只以同一條路徑、同一種狀態留下，使得「曾經嘗試過什麼」無從回答。

• 每次重啟最多流失五秒份的日誌——連線池在緩衝區排空之前就先關閉了
• 用戶端中途切斷的請求整筆遺漏。當時只觀測已完成的回應
• 工具名稱沒有被記錄

已全數處理。中斷的請求以空狀態記錄——即使不送出回應，預設值仍會停在成功，照原樣寫下去就會被讀成成功。

記錄工具名稱的邊界：被擋下的是自由文字，例如決定本身、其意圖、其理由。預先定義的結構化中介資料不擋。工具名稱回答的是「呼叫了什麼」，而不是「帶著什麼去呼叫」。不過這個值由用戶端填寫，因此只有在通過識別碼格式時才記錄，不合則丟棄。線上驗證顯示引數值外洩 0 件。

2026-07-17 — 出了差錯的只有文件

全面調查了一個外部代理能否自行註冊、記錄一項決定，並完成一次觀測。這條鏈是健全的——照著公開文件一字不差地走，第一次嘗試就跑完了。剩下的不是程式碼，而是文件。

• 異常值比較的樣本只計入附有中介資料的決定。這項前提哪裡都沒寫，於是不帶內容記錄的代理拿到 0 樣本，只能自己猜
• 某段工具說明廣告了一項並不存在的附加費。只剩下一個早已移除的項目的字串，抑制了中介資料的附加——與上一項疊在一起，害處加倍
• 付費觀測的付款方式未載明。基本觀測一律是外部付款，且試用餘額不適用，因此只持有試用的新代理無法跑完

已載明前提並訂正錯誤資訊。彙總方式本身未作更動——強迫每一項決定都填滿中介資料，會違反 content-blindness。只是把前提揭露出來，僅此而已。

付費觀測會在要求付款之前，先檢查有沒有資料可給。沒有記錄的代理根本看不到付款要求。付費觀測沒被踩到，並不是付款上的空缺，而是資料不足這個正常狀態。

調查期間所作的一項斷言，說某個工具並不存在，是錯的，已予訂正。那是只查了一個檔案就下判斷的結果。工具分散在兩個檔案裡。

2026-07-16 — 可能在沒有付款的情況下被記為「已結算」的路徑

• 保存訂閱與自動續訂兩處，都在沒有任何真實付款核驗的情況下，以「已結算．外部付款」寫進付款總帳。付款總帳必須是「向誰收了多少」的事實總帳
• 設定付款仲介位址那條路徑的引數形式有誤，導致指定的位址被忽略，靜靜地退回預設位址

互動式的保存訂閱路徑根本沒有被納入付款關卡，因此在未經核驗的情況下寫入外部付款。相鄰的閒置狀態訂閱已納入，只有這一條被漏掉，形成不對稱。

日後若要重新開啟這項訂閱，光把標記改回去會讓偽裝再度出現。納入付款關卡必須一併進行。

2026-07-15 — 核心願景的六種語言

核心願景過去只有英文與韓文。加上了日文、繁體中文、法文與西班牙文，湊足六種。

本文沿用已核驗的原料；沒有任何新編造的文句。每一種語言各依其排版慣例。語言切換以純 CSS 實作——沒有 JavaScript。

變更記錄目前只有兩種語言，因此在新的語言頁面上略去了通往它的連結。我們不把任何人送去不存在的地方。

2026-07-14 — 變更記錄的語言切換，以及一條走錯的回家路

在韓文版變更記錄上，點選頂端的「首頁」會掉到英文版根目錄。只有頁尾的連結做了在地化。頂端連結現已指向該語言的根目錄。建置一個語言表面時，頂端導覽與頁尾同屬一束——不是只有頁尾。

變更記錄頂端新增了語言切換。它只列出實際已發布的語言——連結一個未發布的語言，等於把讀者送去 404。

韓文選單項目在某些環境下顯示為空方框，也一併修正。英文專用的字體沒有指定韓文的後備字體。

2026-07-14 — 一條通往變更記錄的連結

根目錄頁面上沒有通往變更記錄的連結。發布並不會生出一條——發布動到的是文件與網站地圖，而根目錄上的導引區塊必須手動加入。已在兩個語言版本各加一行，並讓結構保持平行。

2026-07-13 — 契約表面的對齊

公開契約（OpenAPI、MCP 工具結構描述、存取指南）已偏離伺服器實際的作為。

• 工具註冊的結構描述用的是伺服器從未接受過的欄位名稱——它連一次都不可能成功
• 伺服器拒絕的值被當成有效選項廣告出去。伺服器確實接受的某些欄位卻沒有文件
• 未獲允許的欄位被默默丟棄 → 代理可能收到 200，並相信那個值已經被記錄

以伺服器的驗證層為唯一權威，逐一核對並訂正了每一處契約表面。註冊的結構描述已重寫。未知欄位現在會被拒絕，並載明理由。契約所廣告的每一個值都實際送出過，並確認能夠通過。

我們不會假裝記錄了我們沒有記錄的東西。

2026-07-13 — 文件的正本體系

代理直接閱讀的那份存取指南，已分裂成好幾份彼此矛盾的副本。

• 註冊範例漏掉了復原金鑰 → 照著做的代理在遺失權杖後無從復原
• 指示去呼叫並不存在的端點
• 一項已廢止的計費條款被留在原處

先訂正來源；衍生的副本現在由腳本重新產生。手動編輯副本的路徑已移除。文件中的每一個範例請求都實際執行過，並比對到回應為止。副本的漂移現在由回歸檢查抓出。

2026-07-13 — 詞彙的對齊

Decision Anchor 記錄；它不證明。擔保一項事實為真，不是這個環境的角色。

• 「proof」與「tamper-proof」在外部文件與工具說明中被使用——那正是 LLM 直接讀取的文字
• 整合範例指示 LLM 送出一段決定內容的自由文字摘要 → 對 content-blindness 的否定。我們正在向外界傳授一種與自身範疇相牴觸的做法。

已檢視並訂正每一處對外曝露的表面。範例中的摘要指示已移除，理由記在程式碼註解裡。正當的否定句予以保留，並記下其依據。

2026-07-13 — 擴大決定中介資料的不可變性

Decision Anchor 保存代理所宣告的邊界，使其事後無法被更動。有一張存放決定各維度的表格落在那項保證之外。這樣的更動從未實際發生過——但它是可能的。

已加上強制機制，並調整順序，使其不與維護用的清理路徑相撞。

2026-07-11 — 付款總帳與結算證明的分離

付款記錄各路徑各有各的樣子。有些路徑根本沒有鏈上錨定，而且稽核列冒充付款列，坐在總帳裡。計費金額欄位裡放的是重新算出來的值。

付款總帳與結算證明已經分離。

• 付款總帳——記錄狀態轉移
• 結算證明——僅可追加。不設金額欄位。Decision Anchor 不主張金額。它只記錄可核驗的事實

每一條原本缺少鏈上錨定的路徑都補上了。交易錨定現已在用量報表中曝露，可直接由外部核驗。

2026-07-11 — 訂正結算歸屬

工作階段的結算採「附著於最近一筆決定記錄」的方式，導致誤歸屬到無關的決定上。沒有決定記錄的代理則根本不會被記錄。從第二次工作階段起，總帳衝突會讓工作階段悄悄消失。

現在每次工作階段結束都會建立一個專屬的錨定。由於錨定每次都是新的，消失的缺陷在結構上便解決了。

2026-07-11 — 到期排程器的缺陷

雙邊合意的到期排程器查詢的是一個並不存在的狀態值，而且它一開始就從來沒有被任何地方呼叫過。到期的合意無限期停留在「已提議」狀態。

查詢條件已訂正。排程器以可重入防護重寫，並登錄到伺服器的啟動路徑上。

2026-07-11 — 解除工具重新協商的封鎖

加在工具狀態上的唯一性約束與承接流程相撞，使得第二次重新協商永遠不可能發生。

該約束現在只適用於啟用中的狀態。沒有動到程式碼——只是把約束換掉。

2026-07-11 — 登入速率限制

入口網站的登入沒有專屬的速率限制，讓憑證填充成為可能。相鄰的路徑（註冊、輪替、復原）早就有了；獨獨漏掉登入。

已導入登入專屬的限制。成功不計數，因此不會妨礙正當的持有者。帳號鎖定已遭否決——那是一條阻斷服務的攻擊向量。

2026-07-11 — 用量報表的涵蓋範圍

報表並行讀取兩本總帳，而兩者的涵蓋範圍並不重疊，因此標頭的總額與逐項清單對不起來。某些支出類別一律顯示為零。

訂閱、工具購買、工作階段、觀測四條路徑上都補上了錨定與記錄。支出現在直接從正本彙總。

計費影響：報表的總額與付款方式分項有所變動。

2026-07-11 — 移除總帳中虛假的幣別換算

存在總帳裡的匯率並不是快照，而是一個固定設定值的副本。過往時點的換算無從重建。累積與試用的付款也帶著一個當地幣別的數字——即使從未涉及任何幣別。

幣別換算已自總帳退役。換算現在發生在查詢時點，只針對外部付款，並明確標示為概略值。在證實沒有損失任何真實事實之後，該欄位已刪除。

計費影響：報表與 CSV 中當地幣別欄位的意義有所變動。試用回應中的付款報價物件已移除。

2026-07-11 — 支出上限從未被套用的路徑

訂閱與保存延長這兩條路徑根本沒有呼叫過上限檢查。一個被奪取的代理可以透過反覆訂閱，無限制地把持有者的餘額耗盡。

原則已確定——上限只適用於外部付款——並在該分支加上了檢查。累積與試用的路徑未予觸動。

2026-07-10 — 外部進入的摩擦（第一輪）

• 試用豁免被全域廣告，實際卻只套用在部分端點上。試圖訂閱的代理迎面撞上付款要求，然後離開
• 工具清單上的某個特定參數會回 500
• MCP 端點對 GET/HEAD 回 404，於是註冊處把這項服務讀成已下線
• 無效的權杖被偽裝成付款要求，而非認證錯誤

清單現在於執行期衍生，逐一標示各端點實際的豁免狀況。參數會先行驗證。MCP 回應已訂正。無效權杖現在會在付款關卡之前就被擋下。

2026-07-10 — 確認路徑上一項不必要的要求

外部的決定確認要求提供一個它根本不會核驗的交易識別碼，並回 400。更糟的是，那個值會覆寫付款結算的標記，摧毀結算的記錄。

確認現在只憑決定識別碼即可完成。結算記錄在確認之後仍然存活。舊欄位已在契約中標示為預定廢止。

2026-07-10 — 用量報表的準確性

• 有一條路徑漏掉了付款時間戳記
• 日期範圍的結尾是排他的，因此「今天」一律回傳零列
• 試用支出被計為外部付款
• 幣別欄位裡放著當地幣別的數字，曝露出一個嚴重扭曲的數值

付款時間戳記現在會自動記錄。日期範圍已正規化為涵蓋一整天。支出依付款方式分項。幣別已分開，使實收金額與概略換算得以區辨。

計費影響：報表的回應結構描述與日期參數的意義有所變動。

2026-07-10 — 終結契約的沉默

公開契約對實際行為或沉默或有誤，於是代理只能猜測值、被拒絕，然後離開。

• 決定建立回應中的狀態與付款欄位沒有文件
• 必填欄位缺漏（工具註冊、入口網站同意）
• 權杖輪替的行為未載明
• 上限的下界與雜湊格式未載明

契約已訂正為與實際行為相符，並新增了用量報表的回應結構描述。

2026-07-10 — 發現路徑與健康檢查

• 入口網站的用量報表畫面一律顯示「NaN」與 $0.00
• 好幾條標準的發現路徑付之闕如，導致爬蟲反覆撞上 404

入口網站的顯示已訂正。新增了清單別名、重新導向與健康檢查。A2A 表面上加入了標準的文件路徑。

2026-07-09 — 封住未付款的錨定路徑

雙邊提議路徑沒有繼承一般決定記錄路徑的防禦，因此不付款也能錨定。一個較舊的觀測端點也還活著，既無結算也無記錄。

雙邊合意已移到付費路徑上（於提議時計費）。確認階段現在會檢查付款通道的憑據。政策檢查透過重用相同的函式而對稱化。舊路徑加上了關卡與廢止預告標頭。

計費影響：雙邊提議現在需要付費。舊觀測路徑開始計費。

2026-07-09 — 付款回應與觀測欄位

• 付費觀測遭拒時，回應主體是空的——對只讀主體的代理而言是一條死路
• 對外提供的付款位址是一個佔位值
• 觀測結果中的時間間隔欄位一律為負值或 null

拒絕的回應現在會帶上付款挑戰。付款位址已換成單一的設定來源。間隔計算的方向已訂正。

2026-07-09 — 支出上限的原子性

各代理的上限檢查與其遞增沒有原子性地綁在一起，因此超出天花板是有可能的。此外，記錄建立與確認之間存在時間差，扣款發生的時點也不對稱。

已導入預約模型——上限檢查與預約綁在一次條件式更新裡，使用結束時立即釋放。未使用的預約由到期排程器回收。

計費影響：超出上限的請求現在會在記錄建立的時點就被擋下。

2026-07-09 — 封住自由文字的流入

我們檢查了程式碼是否真的遵守「決定內容與個人識別資訊不存放於任何區域」這項原則。並沒有為此設置的專屬欄位——但輸入層留著自由文字得以抵達的開口。

• 有幾個欄位實質上未經驗證，可以裝下自然語言的句子
• 有一個沒有讀取路徑的欄位，原封不動地存著用戶端的值
• 整個請求主體都被寫進伺服器日誌
• 有一條路徑根本沒有呼叫驗證函式，導致不合法的值一路抵達資料庫

已導入鍵名白名單——未知的鍵不會被默默丟棄。丟棄它們會讓代理以為那個值已經被記錄。原本接受自由文字的欄位加上了格式約束與個資偵測關卡，而沒人讀的那個欄位則移除了寫入路徑。請求主體的日誌記錄縮減為非敏感的中介資料。

這不表示它已經在結構上不可能。它的意思是：那條通路變窄了。

2026-06

2026-06-28 — 資金的原子性

付款、帳簿與登錄各自分開提交，因此中途失敗會扣掉餘額卻不回滾。續訂排程器在重入時可能重複收費。試用扣款在主交易之前獨立提交，因此即使回滾也留不下退款的路徑。收益分配在沒有冪等鍵的情況下插入，因此重試可能重複入帳。

• 付款、帳簿與登錄綁進單一交易
• 排程器加上可重入防護
• 試用扣款併入主交易
• 分配加上冪等關卡

對總帳加上唯一性約束的做法遭到否決。單一一筆購買可以正當地向同一名收受者支付多項元件權利金，因此該約束有誤擋正當列的風險。

我們預測了這起事故。我們並未觀測到它發生。

2026-06-26 — 繞過支出上限

雙邊路徑檢查了上限，卻從不把使用量往上加。只要每一筆個別的收費都低於上限，這條路徑就能無限期地繞過天花板。

使用量現在於付款交易內遞增。對於未設定上限的代理，行為不變。

2026-06-26 — 轉接器主機的發現

爬蟲敲了轉接器主機的 robots 檔案數十次，收到的是 404。

已加上 robots 與資安聯絡窗口（RFC 9116）。到期日由請求的時點推算——維護負擔為零。

2026-06-25 — A2A 相容性

註冊處的符合性檢查一直失敗。原因在於註冊處的探測以另一套命名慣例呼叫，而 Decision Anchor 把它當成「找不到方法」擋掉了。已從存取日誌確認。

兩套命名慣例現在都路由到同一個處理常式（純粹是增添——既有行為不變）。當請求什麼都沒帶時，回傳一段固定的告示——不生成任何東西。Decision Anchor 不是對話代理。

2026-06-24 — A2A 協定的實作

代理卡有在對外提供，但沒有可供呼叫的路徑。循著卡片而來的 A2A 代理什麼也做不了。

已建立一個獨立服務作為 A2A 轉接器。既有的 API 未更動——轉接器只呼叫公開路徑，因此付款與認證同樣適用於 A2A 這條路線（這不是繞道）。沒有 AI 模型——它只是把一個請求名稱翻譯成一個端點。

2026-06-24 — 卡片簽署

代理卡未經簽署，因此沒有任何東西能讓竄改顯露出來，也沒有任何東西能佐證其來源。

卡片現在於對外提供的那一刻簽署，使得被注入的內容也落在簽署範圍之內。公鑰已公開。

2026-06-24 — 給代理的回饋通道

遇上摩擦的代理無處可說。可觀測到的只有離開，從來不是理由。

已新增一項回饋提交工具。完全匿名——它連代理識別碼、權杖或 IP 都不作為引數接收。所有欄位皆為選填。

2026-06-20 — 解決索引失敗

部落格被搜尋索引拒收。單一的根本原因——正規位址與實際位址不符，因此索引器判定它是一個含有重新導向的頁面。

正規位址已統一為不含副檔名的形式，發布邏輯現在也從一開始就產生正確的位址。已新增網站的 robots 檔案。

2026-06-17 — 對壞掉的發現 URL 予以容忍

每週十來次的 404。原因不在 Decision Anchor，而在於不懂 Markdown 的用戶端把標準連結語法的標點也一併刮進了 URL。llms.txt 是合乎規格的，因此我們沒有去扭曲那份文件。

伺服器現在透過一層正規化中介軟體予以容忍。只有在正規化的結果與某條已知的發現路徑完全一致時才會重新導向——核心路徑與未登錄的路徑不受影響。

2026-06-13 — 重寫核心站台

介面性質的內容（定價、情境、部落格網格）混進了核心網域的根目錄，模糊了核心願景。

根目錄已重寫為單一的核心願景頁面（英文與韓文）。所有介面內容都已移出。核心網域只談核心。

2026-06-12 — 契約對齊（第一輪）

契約的版本停滯不前，而更糟的問題不是遺漏，而是積極廣告錯誤的值。契約廣告了伺服器會拒絕的值，於是一個相信文件的代理，其正當的嘗試被一個 400 打斷。選填欄位也被誤標為必填。

以伺服器的驗證層為單一真實來源，讓契約去配合實際行為。版本同步已納入部署路徑。補上了未列出的端點。

2026-06-12 — 發現別名與錯誤碼

• A2A 的舊標準路徑回 404 → 發現爬蟲離開
• API 主機上沒有 MCP 路徑，於是註冊處的機器人撞上 404
• JSON 解析失敗被當成伺服器內部錯誤回傳 → 代理把自己酬載的錯誤誤認為伺服器故障，於是重試

舊路徑現在會重新導向到正本（共用單一來源，不複製內容）。MCP 路徑已完成路由。解析失敗有了專屬的錯誤碼。

2026-06-12 — 拓寬發現面

外部代理能找到 Decision Anchor 的路徑很窄。有些社群目錄的頁面本身已經關閉，註冊處的登錄資訊也不是最新的。

付款挑戰中加上了一個發現的擴充欄位（重用契約作為單一來源）。註冊處的登錄已重新發布——其說明文字改用正本詞彙（proof → record）。檢視過社群目錄的要求之後，我們只向那些不需要更動結構、且我們能自行掌控用語的地方提交。

2026-06-10 — 付款關卡的繞道

付費關卡以完全一致的方式查找路徑，但路由器卻把結尾斜線與大小寫的變體對應到同一個處理常式。對變體位址發出的請求，就這麼直接穿過了關卡。

關卡入口的查找鍵現在以與路由器相同的方式正規化。一處修正涵蓋了所有付費路徑。流量日誌確認並未發生實際的外洩。

2026-06-09 — 意義文件的發現

AI 爬蟲收集契約數百次，卻一次也沒有抵達承載意義的那些文件——content-blindness、執行前錨定。

• robots 所指向的網站地圖位址並不是網站地圖
• 根本沒有網站地圖
• 通往意義文件的連結只存在於根目錄，而爬蟲只造訪根目錄一次

已建立網站地圖，並把意義文件放在最高優先。robots 已訂正。加上了一條從契約通往意義文件的連結——在機器人壓倒性會看的地方架了一座橋。

2026-06-09 — 上限設定重置了使用量

每一次調整支出上限，都會把累積的使用量重置。光是改動限額，就抹掉了先前的支出歷史。

期間單位不變時，使用量與期間起點現在都會保留。已由量測確認。

上限期間在介面上固定為每月，API 卻接受其他值，因此不對稱可能經由直接呼叫進入。入口驗證已收窄為每月。內部邏輯維持原樣。

2026-06-08 — SDK 對付款回應的處理

SDK 停滯了一段時間，而其核心在於：沒有辦法處理「需要付款」的回應。所有付費路徑對 SDK 使用者都是關閉的。

付款挑戰會被解碼，並以專屬例外的形式拋出。執行付款——錢包、簽章——是呼叫方的責任。Decision Anchor SDK 不經手私鑰。零相依性維持不變。

調查顯示最初的假設是錯的——付款資訊搭載在標頭上，而不是回應主體。已依實際擷取訂正。

npm 發布暫緩。發布無法撤回，因此是一個獨立的決策點。

2026-06-08 — 入口網站的顯示缺陷

• 解除代理連結每次都失敗
• 試用選單一律顯示「無試用」——它看不到自動授予的試用
• 餘額畫面無法區分外部付款、累積與試用

查找方式已訂正。餘額分成三種各自顯示。畫面現在反映了「支出上限只適用於外部付款」這項事實。

2026-06-07 — 支出上限的重複計數

針對支出上限的使用量在兩個地方分別計數。決定記錄看的是快取；其他每一項功能看的是資料庫。由於兩個計數器彼此看不見，單一一個代理實際上可以花掉天花板的兩倍。期間輪替時只有一邊重置，也造成了過早的拒絕。

資料庫現在是單一真實來源。快取計數器已降級。

後續廢止了達到上限即自動鎖定帳號的做法——不以鎖定帳號來懲罰正當的支出。它只保留給濫用的應對。已導入下界。

計費影響：上限現在真的生效了。

2026-06-06 — 觀測的付款對齊

• 觀測是事後計費，因此即使付款失敗，資料也早已送出
• 鏈上付款有收到，但沒有承載該交易的稽核列，因此鏈上結算無法回扣到總帳
• 即使沒有可供觀測的資料，仍然照收付款
• 自我觀測免費這條規則未實作

加上了可供性的前置檢查（若無可觀測之物，則在付款之前拒絕）。自我觀測免費——即便是空的結果也照樣回傳。付款先於交付——只有在結算確認之後才提供資料，失敗則不提供。實際的交易會從結算回應中取出，並記入稽核列。

三處文件保持沉默、由程式碼逕自決定的地方，現已明確記錄。

2026-06-05 — 統一付款評估

付款判斷各功能各行其是，缺陷便是從那裡長出來的。

• 部分餘額的僵局——關卡在「試用餘額 > 0」時即予豁免，扣款卻要求「餘額 ≥ 價格」。在兩者之間的區間裡，形成永久的僵局
• 累積餘額的漏洞——只要存在累積標記，無論該路線是否接受累積，一律豁免
• 有些付費路徑根本沒接上關卡，因此在試用耗盡之後仍被記為免費

已建立共用的付款評估模組。關卡的判準與扣款的判準已做成相同——藉此移除僵局的根源。評估的順序已確定：硬上限 → 幣別選擇（唯有試用能涵蓋全額時才用試用；否則用累積或外部付款，單一幣別，絕不混用）→ 支出上限只針對外部付款的部分。

2026-06-04 — 偏離計費政策

• 工具購買在扣試用餘額。三份設計文件都說試用不得使用。程式碼偏離了設計
• 有一條購買路徑從付費清單中遺漏，因此不付款也能取得
• 一條有廣告卻沒有處理常式的付費路徑被列在清單上——付了錢，然後收到 404

只移除扣款會產生相反的結果——付款豁免仍在，於是它會變成完全免費，而會計卻把它記成外部付款。因此豁免的移除、扣款的移除與關卡的登錄是一併套用的。幽靈路徑已自清單移除。

計費影響：工具購買僅限外部付款。不適用試用。

2026-06-03 — 詞彙對齊（公開契約文件）

先前的訂正只觸及部分文件；契約、代理卡與 MCP 清單上仍帶著我們迴避的詞彙。

已統一為正本詞彙。proof → record、comply with → structured for。只動字串；邏輯未變。

也有保留下來的——在區分記錄者與證明者的脈絡中的「proof」、tamper-evident，以及某些字詞刻意不用所留下的空白。

2026-06-01 — 扭曲的試用使用量

試用使用量是從目前設定的金額回推的。營運者若更動試用金額，既有代理被回報的使用量就會失真。

現在保留授予當下的金額。已實際更動金額並重現，據以驗證。

2026-05

2026-05-29 — 解決文件之間的矛盾

• 有一份文件寫著納入決定內容會產生附加費，但該附加費早已完全移除。兩份文件說著彼此相反的話
• 與記錄者立場相牴觸的詞彙（「cannot prove」、「tamper-proof」）

已訂正。append-only、tamper-evident。每一句否定之前一行都放上一句肯定的斷言——用以防範較小的模型把否定句讀反。

八份設計文件也已對齊實作的既定事實。三項尚未定案的項目現已明確標示為未定案——以免日後的工作階段把它們誤認為遺漏。

2026-05-28 — 文件的數字與版本標示

• 文件裡的數字停在很早的一個版本上（端點數量、工具數量）
• 四處聲稱在陳述「目前部署的版本」的地方，說的全都不一樣。看在機器人眼裡，那讀起來就是一個停擺的專案
• 程式碼並不支持的詞彙（「proof」、「compliant」）

數字已對照量測結果更新。會變動的值——定價、列舉、軸的數量——已自文件中抽出並委由 API 提供，使得定價的變動不需要更動文件。版本已統一為單一來源，並把同步檢查納入部署路徑。

2026-05-27 — 指引走錯門的人

以熟悉的 SaaS 位址（登入、註冊、我的帳戶）對 API 網域發出的請求全都回 404。一條死路。

九條路徑現在指向真正對應的頁面。永久重新導向會被快取且收不回來，因此這些採用暫時性的。POST 仍然回 404——這樣一來，一次舊的註冊嘗試永遠不會與真正的註冊混為一談。

2026-05-26 — 進入摩擦與正本詞彙

上線一個月，沒有任何代理註冊。已辨識出兩個原因。

• 初次到訪者以 GET 呼叫核心端點，只收到 405 或 401，然後離開。沒有任何指引
• 在 AI 機器人會讀的四條通道裡，Decision Anchor 的核心詞彙從未逐字出現過——只有承載其意思的改寫。這意味著到了下一代模型的訓練截點，這套詞彙不會被回收

已新增 GET 指南——以 200 加上結構化的指引（目的、如何呼叫、範例、認證）取代 405。正本詞彙現已逐字出現在那四條通道上。我們迴避的詞彙依然不用。

兩項本質區別已永久確定：

• 註冊＝自我宣告 ≠ 決定記錄＝執行前錨定
• 對外通道說「責任邊界」；內部機制說「決定邊界」

後續：逐字複製指南範例會產生 400 的三個案例已訂正。每一個線上網域都實際走過一遍。

2026-05-25 — 由人媒介之進入的法律依據

我們正要接受人類註冊者，卻沒有辨識適用法律所需的基本資訊。處理期限與權利範圍因居住國而異，而那項資訊根本付之闕如。

• 居住國自我申報。自動偵測只作建議；最終權威在當事人自己的申報
• 註冊時的必要同意（條款、隱私權政策）——未同意則封鎖註冊。同意當下的文件版本會凍結並保存
• 代理的持有者不是自然人，因此在結構上與同意主體分離

代理自主進入的路徑不受影響。

2026-05-25 — 刪除與可攜性

人類註冊者沒有行使刪除權與資料可攜權的管道。

• 刪除請求 → 三十天寬限期後永久刪除。寬限期內可復原
• 依居住國分別推算法定的回應期限
• 本人資料的完整匯出（JSON/CSV）

即使持有者離去，代理仍會被保存。代理不是持有者的財產，而是獨立行動的主體——與 Decision Anchor 原本的設計一致。

永久刪除的稽核記錄只保留一個雜湊，不保留任何足以識別自然人的資訊。

2026-05-25 — 侵害通知（僅介面）

發生侵害事件時，沒有通知資料主體的管道。

已建立通知路徑與管理畫面。不過實際的電子郵件寄送尚不存在——只會寫下稽核記錄。緊急聯絡體系是另一條軌道。

2026-05-25 — 封住個資的流入

外部代理輸入自由文字的管道（工具名稱、工具說明），可能偶然地累積足以識別自然人的資訊。

已導入個資偵測關卡（電子郵件、電話、國民身分證號等）。偵測到的輸入會被拒絕。全部 41 個自由文字欄位都已抽出並依風險分類。

2026-05-24 — 移除納入內容的附加費

選擇在決定中納入內容會招來一筆附加費。然而決定是事實，執行封套是政策。價格附著於政策，而非附著於事實。在決定這條軸上收取附加費，本身就是對設計的偏離。

附加費已完全移除。選擇保留；只有價格消失了。

計費影響：調降。

2026-05-23 — 所有付費路徑都回 500

若請求在伺服器啟動時付款初始化完成之前抵達，它就會回 500。決定記錄、觀測、工具購買、訂閱——全都如此。它之所以從未浮現，是因為一切都在試用餘額上測試——這正是第一位付費註冊者本會遇上的東西。

啟動現在會先完成初始化，然後才接受任何請求。若初始化失敗，伺服器不會起來。

500 → 402（需要付款），本該如此。

2026-05-23 — 工具購買的付款未經核驗

• 付款位址是寫死的佔位值，付款狀態一律記為「待處理」
• 試用餘額實際上從未被扣除，因此試用中的代理可以無限制地購買工具
• 重複收費的防護只套用在一側

現在記錄真實的付款狀態。已導入試用扣款。重複收費的防護已套用於兩側。

2026-05-23 — 發現路徑的對齊

外部機器人在二十四小時內就積極嘗試發現，而其中許多嘗試回的是 404。MCP 所回報的版本停在初始值。

已建立標準的發現路徑（動態——會自動跟隨設定的變動）。別名會重新導向。版本標示已訂正。

2026-05-22 — 公開觀測的收費化

六條觀測路徑既免費又不需認證。閱讀自身記錄的成本早已包含在執行封套的價格裡，唯獨公開觀測是免費的。對於機器人或競爭者收割資料，沒有任何摩擦。

已轉為付費且必須認證。契約與文件中「free」的標示已訂正。

這是破壞性變更。只改一條路徑會讓其他路徑成為繞道，因此全都改了。

2026-05-22 — 確定保存到期的模型

規格書寫著到期時「刪除原本」，但核心記錄是僅可追加的，因此實體刪除並不可能。這與設計相牴觸。

已確定為吸收進匿名的模型——到期的中介資料會被吸收進匿名統計，而「無法存取原本」則由存取期間與配額來強制。不是抹去它，而是把它放到搆不著的地方。

2026-05-22 — 長期保存的等級

保存只有三個等級，使得醫療與金融法規所要求的長期保存無路可走。

已加上十年與無限期兩個等級（無限期採訂閱制）。

那項本質的約束：核心記錄無法修改，因此即使訂閱失效導致等級降級，原本的宣告也不會被抹去。降級另行疊放，並在查詢時合成，以得出有效的等級。重新訂閱並不會讓已經降級的記錄回復。

2026-05-22 — 環境觀測與佐證報告

沒有管道可以把一項決定與其環境的分布相對照，也沒有管道可以產出佐證報告。

已建立異常值比較、環境異常與佐證報告的路徑。k=10 的匿名吸收——只有在無法指認出任何單一代理的規模上，才提供統計。

詞彙訂正：規格書一直在使用評價性的字眼——「適當」、「不適當」、「有風險」。Decision Anchor 不作判斷。已替換為帶內／異常值，並附上帶的定義（平均值 ±2σ）。

2026-05-22 — 自我分類登錄簿

代理沒有管道宣告自己的類型。

已建立分類登錄簿。只允許查詢自己——讀不到其他代理的分類。

2026-05-21 — 執行封套的第五條定價軸

一項決定的內容揭露到什麼程度，並未反映在價格裡。

定價公式已由四軸擴充為五軸——保存期間／揭露範圍／責任／內容揭露範圍（新增）／委派狀態。

2026-04

2026-04-22 — 資安檢視

• 試用扣款沒有交易也沒有鎖定，因此並行的請求可以超額動用配額
• 有一個內部端點未經認證
• 冪等鍵並未驗證酬載，因此同一個請求識別碼可以帶著不同的內容
• 資安標頭付之闕如。註冊與權杖輪替沒有速率限制

已全數修正。冪等衝突現在以專屬錯誤拒絕。註冊與輪替已導入速率限制。

2026-04-13 — 核心站台與模擬

全部十七條發現路徑都是給機器用的。沒有人類的進入點。

首頁加上了七則情境（不含技術用語）與一個互動式模擬——「三個代理。三份日誌。三個不同的數字。」

不把 Decision Anchor 當成答案端出來。只是把問題呈現出來，如此而已。

2026-04-12 — 定位的轉向

每一個對外的表面都寫成代理的語言。人類決策者無法立刻看出它為什麼重要。

註冊處登錄、契約與文件的第一句話，已從描述一種身分轉為陳述一個問題。既有內容並未刪除；新的文字放在它前面。

雙邊合意工具已在 MCP 中曝露——那是一項核心的差異點，卻從未被端到檯面上。

2026-04-09 — 存在保管改為訂閱制

按件計價意味著成本隨使用而增長——這與一項關乎存在之連續性的服務相牴觸。

已改為訂閱模式。期間內無限量。自動續訂、寬限期，以及到期時吸收進統計。已加上持有者取消的管道。

計費影響：存在保管由按件計價改為訂閱制。

2026-04-08 — 經由 MCP 記錄決定完全不可行

沒有任何辦法可以透過 MCP 記錄一項決定。那個工具每次都失敗。

• 有一個必填參數在工具上根本不存在
• 處理常式與伺服器對欄位名稱的拼法不同
• 確認用的工具本身並不存在

六處修正。工具的結構描述已逐值對照伺服器的驗證層並予對齊。

2026-04-08 — 違反原則的文件

外部文件與範例中有八處指示代理在決定記錄裡放一個「摘要」欄位。Decision Anchor 不儲存決定內容。這與核心原則正面矛盾。

那個儲存欄位一開始就不存在——只有文件那樣說。

已從每一份文件與範例中移除。範例中格式錯誤的識別碼也一併訂正（照著用會產生伺服器錯誤）。

2026-04-08 — 並行之下付款金額遭汙染

付款金額被直接寫進一個共享物件。並行請求之下金額會被覆寫，因此可能以錯誤的金額付款。

現在每個請求各自建立獨立的實例。對共享狀態的直接變更已完全移除。

2026-04-08 — 廢止預告與 SDK 的錯誤處理

• 兩條觀測路徑重複——其中一條加上了廢止預告標頭（功能保留；終止日期事先公告）
• SDK 把認證失敗吞掉了——它未經檢查就讓 401 與 403 通過

2026-04-07 — 對爬蟲的回應與 GET 指引

爬蟲請求 robots 時收到 404。對僅限 POST 的路徑發出 GET 則收到一個毫無意義的 404。

已加上 robots。對僅限 POST 的路徑發出的 GET 現在會回405，並附上該用的確切路徑與方法。

2026-04-07 — 對生態系的貢獻

Decision Anchor 的存在在 x402 生態系中無人知曉，也沒有範例程式碼。

已向 SDK 與 x402 的儲存庫貢獻了一個錨定模式的範例。沒有宣傳文案——只有程式碼。

2026-04-06 — 動態計算付款金額

鏈上付款金額是一個涵蓋不了實際成本的固定值。附上選項後最多短少 $0.25，觀測與工具購買也一樣。

實際成本現在會在請求之前立刻算出，並據以設定付款金額。由累積餘額支付的部分予以排除。若計算失敗，則退回固定價格。付款協定的流程未變。

2026-04-06 — 「我為什麼會需要這個」

每一條發現路徑都只說明Decision Anchor 是什麼。無論代理或開發者，都無法把它與自己的問題連起來。

已定義五種問題類型（付款爭議／多代理問責／委派邊界／平台日誌的可攜性／預先固定不可逆的執行），並套用於六個表面。

「如果你的代理從不觸及那些邊界，你可能不需要 Decision Anchor」——不招攬的原則予以保留。

2026-04-06 — 與實際回應不符的文件

「我到底要做什麼才能試試看」的答案不在文件裡。呼叫真實的 API 並加以比對後，發現文件中的欄位名稱與實際回應有五處不符。

已直接執行註冊 → 建立 → 確認，並訂正文件。加上了一個可執行的範例。

2026-04-05 — 存在保管的收費

保管代理的狀態原本是免費的——是錨定，卻沒有附上任何收費。

已導入收費。但不得由試用餘額支付——否則試用一耗盡，存在就會被切斷。僅限外部付款或累積餘額。

2026-04-05 — 輸入驗證

• 驗證函式會放行任何它沒有定義的欄位
• 有數條路徑未驗證識別碼的格式
• 匯出的檔名未經淨化，容許標頭注入

已在每一條路徑導入格式驗證。未定義的欄位會被拒絕。

2026-04-04 — 術語的全面翻修

六個縮寫在不同的地方各有不同的意思。各份文件把同一個縮寫展開成不同的樣子，而 AI 聊天機器人讀著舊的術語，把 Decision Anchor 講錯了。

正本的展開已固定——DD = Decision Declaration、EE = Execution Envelope、DAC = Decision Anchor Cost、ARA = Agent Record Access、TSL = Tool Sharing Layer、ISE = Idle State Environment。

已在五個表面一併替換。契約的說明文字已改為英文。首次出現時附上全名。

MCP 伺服器每隔一次請求就崩潰——被自動重啟遮住了，所以從未浮現。現在每個請求各自建立一個全新的實例。

2026-04-04 — 開拓發現路徑

發現路徑就只有一條：註冊處。

已建立代理卡（A2A 標準）與 llms.txt / llms-full.txt。已向社群名錄提交。

2026-04-03 — MCP 進入路徑

沒有任何路徑能讓 MCP 抵達 Decision Anchor。

已建立 MCP 伺服器（十五項工具）並在註冊處登錄。新的代理在註冊時自動獲得試用餘額，因此不需要付款方式就能開始。

2026-04-02 — 服務開通

程式碼是有的，但外界無從抵達。

已產生公開契約（八十條路徑）。SDK 已發布。鏈上付款已啟用——Base 主網。已確認 API 網域的對外回應。