docs: refine memory consolidation skip ticket
This commit is contained in:
parent
46765404bf
commit
5b3b16c4b2
|
|
@ -2,42 +2,58 @@
|
||||||
|
|
||||||
## 背景
|
## 背景
|
||||||
|
|
||||||
`memory-audit-log` 実装後、TUI actionbar に `memory consolidation skipped: no_staging_entries` が表示されるようになった。これは一見すると「staging が無い」状態に見えるが、実際の workspace には `.insomnia/memory/_staging/*.json` が残っている場合がある。
|
`memory-audit-log` 実装後、TUI actionbar に `memory consolidation skipped: no_staging_entries` が表示されるようになった。これは正常な idle/no-op でも頻繁に発生するため、actionbar 上では「何かが skip され続けている」ように見える。
|
||||||
|
|
||||||
現状の原因は二つある。
|
また、workspace に `.insomnia/memory/_staging/*.json` が残っているのに、現行 schema として読めないため valid staging entry が 0 件になり、`no_staging_entries` と区別できない場合がある。今回観測された主因は旧 schema の staging file で、`source.session_id` を持ち、現行 schema が要求する `source.segment_id` を持たないものだった。
|
||||||
|
|
||||||
1. `run_consolidate_once` が成功後に backlog drain のため loop し、直後の空確認で `skipped: no_staging_entries` を emit する。これにより、直前の `completed_record_changes` 表示が actionbar 上で上書きされる。
|
旧 schema staging の後方互換・migration は求めない。この workspace に残っている旧 staging は必要に応じて手動で削除 / 退避する。実装としては、壊れた staging / 現行 schema として読めない staging がある場合に、`no_staging_entries` と誤認しない観測性だけを持たせる。
|
||||||
2. 旧 schema の staging file は `source.session_id` を持ち、現行 schema が要求する `source.segment_id` を持たないため parse で skip される。結果として、ファイルは存在するのに valid entry が 0 件となり、`no_staging_entries` と記録される。
|
|
||||||
|
|
||||||
この状態は機能停止ではないが、観測面として misleading であり、memory 機構の稼働状況を人間が誤解しやすい。
|
|
||||||
|
|
||||||
## 方針
|
## 方針
|
||||||
|
|
||||||
Audit log には worker の skip / no-op を残しつつ、actionbar には人間が見る価値のある状態だけを出す。特に successful consolidation の直後に発生する drain 終端確認の `no_staging_entries` は actionbar に出さない。
|
Audit log には worker の skip / no-op を残してよいが、actionbar には人間が見る価値のある memory worker 状態だけを出す。
|
||||||
|
|
||||||
また、staging directory にファイルがあるが current schema として読めない場合は、`no_staging_entries` ではなく invalid staging が存在することを audit log から分かるようにする。
|
特に以下は actionbar に出さない。
|
||||||
|
|
||||||
|
- `no_staging_entries`
|
||||||
|
- successful consolidation の直後、backlog drain 終端確認で出る空確認 skip
|
||||||
|
- post-run / periodic check で staging が本当に空だっただけの skip
|
||||||
|
- 通常運用で頻出する no-op / idle skip
|
||||||
|
|
||||||
|
一方で、以下は actionbar に出してよい。
|
||||||
|
|
||||||
|
- consolidation の started / completed
|
||||||
|
- record changes を伴う completed
|
||||||
|
- failed / error
|
||||||
|
- invalid staging が存在するなど、人間が確認すべき状態
|
||||||
|
|
||||||
|
staging directory に file があるが current schema として読めない場合は、audit log 上で invalid staging の存在と件数が分かるようにする。actionbar に出す場合も、`no_staging_entries` ではなく invalid staging と分かる文言にする。
|
||||||
|
|
||||||
## 要件
|
## 要件
|
||||||
|
|
||||||
- consolidation が `completed` した直後の drain 確認で発生する idle skip が、直前の actionbar 表示を上書きしない。
|
- consolidation が `completed` した直後の drain 確認で発生する idle skip が、直前の actionbar 表示を上書きしない。
|
||||||
- 例: `completed_record_changes` の直後に `no_staging_entries` を actionbar へ出さない。
|
- 例: `completed_record_changes` の直後に `no_staging_entries` を actionbar へ出さない。
|
||||||
- audit log へ残すかどうかは実装判断でよいが、UI event としては抑制する。
|
- audit log へ残すかどうかは実装判断でよいが、UI event としては抑制する。
|
||||||
- 通常の post-run check で staging が本当に空の場合も、actionbar に `no_staging_entries` を毎回出さない。
|
- 通常の post-run check / periodic check で staging が本当に空の場合も、actionbar に `no_staging_entries` を出さない。
|
||||||
- idle/no-op 状態は audit log 側で確認できればよい。
|
- idle/no-op 状態は audit log 側で確認できればよい。
|
||||||
|
- `threshold_not_reached` は通常運用の no-op として扱い、actionbar へ常時表示しない。
|
||||||
|
- audit log 側では `no_staging_entries` と区別して記録する。
|
||||||
- `list_staging_entries` あるいはその呼び出し側で、invalid / parse-failed staging file の存在を区別できるようにする。
|
- `list_staging_entries` あるいはその呼び出し側で、invalid / parse-failed staging file の存在を区別できるようにする。
|
||||||
- 少なくとも invalid count が audit reason または structured field から分かる。
|
- 少なくとも invalid count が audit reason または structured field から分かる。
|
||||||
- 例: `no_valid_staging_entries invalid=6`。
|
- 例: `no_valid_staging_entries invalid=6`。
|
||||||
- `threshold_not_reached` と `no_valid_staging_entries` / `invalid_staging_entries` は区別される。
|
- `threshold_not_reached` と `no_valid_staging_entries` / `invalid_staging_entries` は区別される。
|
||||||
- 既存の old schema staging を自動 migration / delete しない。
|
- old schema staging file の自動 migration / 自動削除 / 自動 archive はしない。
|
||||||
- `source.session_id` と `source.segment_id` は意味が違う可能性があるため、この ticket では観測性改善に留める。
|
- 後方互換は不要。
|
||||||
- 必要なら後続で archive/drop/migration 方針を決める。
|
- 既存 workspace の旧 staging は手動整理でよい。
|
||||||
|
- 実装側では、現行 schema として読めない staging を invalid として観測できればよい。
|
||||||
|
|
||||||
## 完了条件
|
## 完了条件
|
||||||
|
|
||||||
- successful consolidation の直後に actionbar が `no_staging_entries` で上書きされない。
|
- successful consolidation の直後に actionbar が `no_staging_entries` で上書きされない。
|
||||||
- staging directory に parse 不能な `.json` がある場合、audit log が `no_staging_entries` ではなく invalid staging の存在を示す。
|
|
||||||
- staging が本当に空の periodic/post-run check は actionbar にノイズを出さない。
|
- staging が本当に空の periodic/post-run check は actionbar にノイズを出さない。
|
||||||
- consolidation skip / invalid staging の挙動を確認する test がある。
|
- `threshold_not_reached` が actionbar を継続的に上書きしない。
|
||||||
|
- staging directory に parse 不能な `.json` がある場合、audit log が `no_staging_entries` ではなく invalid staging の存在を示す。
|
||||||
|
- invalid staging を actionbar に出す場合、`no_staging_entries` ではなく invalid staging と分かる表示になる。
|
||||||
|
- consolidation skip / invalid staging / actionbar 抑制の挙動を確認する test がある。
|
||||||
- `cargo fmt --check` と関連 crate の test が通る。
|
- `cargo fmt --check` と関連 crate の test が通る。
|
||||||
|
|
||||||
## 範囲外
|
## 範囲外
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue
Block a user