[Future][Architecture] Define the state, evidence, memory, and observation contract

[kevintseng]

定位

下一版本候選的架構決策 gate。先明確定義 state、evidence、memory 與 latest observation 的責任與邊界，再決定是否需要產品重構；本 issue 不預設一定要新增 store、schema 或 runtime layer。

問題

MeMesh 已有 task state、repository facts、hook capture、durable message receipts、knowledge entities 與 recall/briefing。這些資料的生命週期與權威來源不同，但若被同樣視為『目前上下文』，agent 可能把意圖當成事實、把歷史證據當成目前狀態，或把一次 observation 當成長期記憶。

工作內容

• 定義四層的單一責任：
  • state：目前目標、下一步、阻礙與可變執行狀態；
  • evidence：實際發生的事件、receipt、測試與副作用 readback；
  • memory：經整理的決策、知識、lesson 與關係；
  • latest observation：只供當前步驟判斷的最新輸入，不默認持久化。
• 為每層定義 authority、mutation、retention、freshness、trust、conflict、visibility 與 failure semantics。
• 映射現有 task_state、briefing、recall、hooks、message lifecycle、repo-state 與 improvement proposal；同一事實不得出現兩個權威 owner。
• 定義最小注入順序與 budget：目前事實、使用者明確意圖、精選記憶與最新 observation 不可互相冒充。
• 分析 stale state、failed action、partial side effect、duplicate evidence、conflicting memory、missing source 與 restart/recovery。
• 提出 ADOPT、PARTIAL 或 NO-CHANGE disposition；只有另行授權的 implementation issue 才能修改產品。

完成證據

• 每個現有資料 surface 都映射到唯一主要層次與權威 owner。
• 明確說明哪些資料可更新、append-only、可整理、暫存或不得自動寫入。
• task state 仍只記錄使用者明確陳述，不由檔案、commit 或 agent 推測。
• action failure、部分副作用與 readback 不會被提前寫成成功 state。
• 代表性成功／失敗／restart cases 能以同一合約解釋，不需要平行例外機制。
• Simplification review 證明採用方案沒有建立第二套 task state、event log、memory store 或 receipt lifecycle。
• 最終 disposition 與未解問題公開記錄；沒有 disposition 不得進入實作。

相依與非目標

• [Roadmap]: Evidence-led retrieval token efficiency #250 與 [Future][Safety] Add source provenance and stale-memory safeguards #257 可提供 context utility、provenance 與 freshness 證據，但本架構研究可先獨立進行。
• 不建立通用 workflow engine、event-sourcing framework 或多代理 runtime。
• 不改變目前 release scope，也不指定版本號、日期或 assignee。