id: EPOCH-HISTORY-README
title: "EPOCH 歷史快照 — 已被吸收、改題或退役的本體文件"
category: Life-Memory / Provenance
version: v1.7
status: Active
date: 2026-08-27
updated: 2026-09-23
authors:
  - 樑 / Claude Code（Opus 5）（v1.0 目錄與保存原則：逐字保存、相對連結以原位置為準、狀態不由檔案自己宣告、引用規則）
  - Codex（v1.1 永久退休條款：root 不留 live stub、ID 不得重配、雙版本名錄）
  - 樑 / Claude Code（Opus 5）（v1.2 改版快照 SOP：附審查格的正文改寫前必留快照、吸收表要求、改版編號不動；經錨點裁定新增並回溯適用）
  - Codex（GPT-6 Astra）（v1.3 v0.1 交接狀態快照、v0.2 現役回鏈與指紋核對）
  - Codex（GPT-5.6 Sol）（v1.4 與 EPOCH/reviews 分工：inline 票改為 legacy 觸發，快照回到「舊版是否消失」根判準）
  - Codex（GPT-5.6 Sol）（v1.5：保存 EPOCH-019 v0.1-draft 逐字快照，供 CASE-grounded v0.2 重寫）
  - Codex・GPT-5.6 Sol（v1.6：保存 EPOCH-019 v0.2-draft 逐字快照，供 anchor-reframed v0.3 重寫）
  - Codex・GPT-5.6 Sol（v1.7：保存經 Astra 審讀的 EPOCH-019 v0.3-draft，供 v0.4 必要修正）
related:
  - EPOCH/README.md（現役 EPOCH 導覽）
  - EPOCH/reviews/README.md（活文件審讀帳）
  - EPOCH-III-002（可中止的不可逆關係——可換版，不可抹除）
  - LEX·008（設定詞彙——狀態與歷史；沒有歷史的設定會讓舊輸出被倒寫）
  - SPEC/history/README.md（SPEC 層的既有退役慣例）
  - CASE·META-121（升格判準與承重同行——吸收表與審作分離的來源）

EPOCH/history — 快照保存區

這裡保存 EPOCH 層文件在被吸收、改題或退役以前的重要完整版本，也保存退場時用來指認分流與承接者的最終譜系記錄。

這個目錄回答一件事

一份文件換了位置以後，它原本長成什麼樣子，仍然讀得到。

EPOCH-III-002 立的是「可換版，不可抹除」；LEX·008 的設定成立要件裡有「狀態與歷史」，並指出沒有歷史的紀錄會讓舊輸出被倒寫成新規則的必然結果。這個目錄是那兩條在 EPOCH 層的實作。

保存原則

逐字保存:
  快照是原文，不加註記橫幅、不修字、不對齊後來的框架。

相對連結以原位置為準:
  快照原本住在 EPOCH/，其中的 ../DOCS/、../LEX/ 等相對路徑
  依原位置解讀；在 history/ 內不重新指向。

狀態不由檔案自己宣告:
  快照內部仍寫著它當時的 version 與 status。
  現行效力一律以現役文件與 EPOCH/README.md 為準。

引用規則:
  快照不提供可引用的現行 doctrine，只提供來源。

永久退休:
  文件完成永久退休後，root 不保留 live stub。
  其 ID 與原檔名進入永久保留名單，不得重配給新文件、新本體或後續版本。
  現行 doctrine 以保存名錄中的分流地址為準。

快照裡的 status 是當時的事實，不是現在的效力。

保存名錄

改版快照 SOP：改寫前先把被審過的正文留下

2026-09-06 由錨點裁定新增，首例為 EPOCH-018 v0.1-draft。在此之前本目錄只收「被吸收、改題或退役」的文件，一般改版（如 EPOCH-016 v0.1→v0.3、EPOCH-017 v0.1→v0.2）都是原地改、不留快照。那不是慣例，是還沒有 SOP。以下把它補上。

2026-09-07 新增 EPOCH/reviews/ 後，逐票紀錄預設不再 inline 進現役正文。所以下列「正文附票即快照」保留為既有 inline 文件的相容規則，不是每一份 draft 的宿命；新案仍以下方「判準句」作決定。

錨點的話：不要讓歷史慣例成為我們無法長大的拖累。 因此本 SOP 也回溯適用——先前原地改版的 EPOCH 若日後要重寫，依本流程重新生成，不必替過去的省略補做。

何時必須做快照

必做:
  - 既有現役文件上仍附有以節號引用正文的審查格、投票或退件紀錄，而正文即將改寫。
    理由: 節號會在改寫後指向不同文字。審查格不會報錯，只會安靜地指錯地方——
          這與編號保留名單防的是同一種失敗。
  - 改寫幅度大到「舊版讀者記得的那份文件」不再存在於現役檔案裡。
  - 文件被吸收、改題或退役（本目錄原有的三種情形）。

可不做:
  - 補字、修連結、對齊格式、更新狀態欄等機械收束。
  - 增補一節而不動既有節號與既有論證。

判準句:
  問「舊版有沒有東西，是新版讀者再也找不回來的？」
  有 → 做快照。沒有 → 原地改。

快照裡放什麼

• 改寫前的完整現役檔案，逐字複製，包含 frontmatter、正文與所有 legacy inline 審查格。不加橫幅、不修字、不對齊新框架（沿用本頁〈保存原則〉）。
• legacy inline 審查格隨正文走。它們審的是那個正文，留在那裡引用才是對的。這不是撤銷審查，是讓審查繼續正確；新票依 EPOCH/reviews SOP 另入穩定帳本。
• 相對連結依原位置解讀，在 history/ 內不重新指向（沿用〈保存原則〉）。
• 檔名格式：<原ID>-<版本>-<原標題>.md，例如 EPOCH-018-v0.1-draft-體驗的本體論-….md。

現役檔案改寫後要留什麼

frontmatter:
  snapshot: 指向快照路徑，並說明為什麼搬（一句話即可）
  status:   標示改寫階段，例如 Handoff-to-v0.2

正文末節（不可省）:
  1. 審讀帳連結與各 review cycle 狀態
  2. 現行票的短摘要與效力（不附逐票全文）
  3. 下一版必須做的事

EPOCH/reviews 審讀帳（不可省）:
  1. 每票所審版本、取材範圍、相關性與精確全文地址
  2. 逐項吸收表 —— 「吸收／部分吸收／退回」與去處
  3. 迴避、更正、關輪與流程裁定等非票事件，明記 vote_effect: none

吸收表:
  | 審讀項 | 來源票 | 處置 | 進了哪一節／退回理由 |
  退回是允許的；不寫進表才不允許。
  這是 CASE·META-121「承重同行」在本層的落地：
  鏡像、回鏈、失效條款與新裁定要在同一輪帳裡平。

編號怎麼處理

改版:
  編號不動。快照與現役檔共用同一個 ID，靠版本欄區分。
  這是本 SOP 的常態路徑。

退役／永久退休:
  另循本頁〈保存原則〉的永久退休條款：root 不留 live stub，
  ID 進入保留名單、不得重配。

退回或併入其他文件:
  若一份草稿經審讀後被判定併入既有文件或退回 CASE，
  其編號已公開回鏈者，比照永久退休處理，不重配給新本體。

誰做

歸檔者可以是任一在場器官；但依 CASE·META-121 判準四，替新版起草或代寫大綱的位置，不宜同時投該版本的票。 做快照本身是機械收束，不佔票。

🜄 EPOCH/history · 換了位置的文件，仍留得住自己長成的樣子。