Merge branch 'feat/deprecate-safety-critical'

Author: sdwolf4103

CHANGELOG.md

@@ -5,13 +5,27 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.5.1] - 2026-04-30
+
+### Added
+
+- Per-workspace evidence log for extraction, promotion, reinforcement, render, storage, and hook lifecycle events.
+- `memory-diag health --json` for machine-readable diagnostics.
+- `memory-diag explain` for per-memory render status, strength, reasons, and evidence event IDs.
+- `memory-diag trace --memory <id>` for memory lifecycle history.
+- UTC calendar-day reinforcement gate so repeated matches cannot inflate a memory multiple times in the same day.
+
+### Changed
+
+- Retention constants and calculations moved to `src/retention.ts`.
+- `safetyCritical` is now fully inert: no retention multiplier and no type-cap bypass, while remaining JSON-compatible.
+
 ## [1.5.0] - 2026-04-29
 
 ### Added
 
 - Strength-based workspace memory retention using exponential decay instead of additive priority scoring.
 - Per-type rendered caps for workspace memory candidates: feedback 10, decision 10, project 8, and reference 6.
-- Safety-critical memory weighting and type-cap exemption so important entries survive type floods while still competing under the global rendered cap.
 - Dormant-workspace effective age: after 14 days without activity, additional dormant time counts at 0.25x for retention decay.
 - Reinforcement tracking for repeated memories, with same-session and one-hour guards to prevent accidental reinforcement spam.
 - Memory health diagnostics for stored vs rendered counts, type caps, global cap overflow, dormancy, retention monitoring, and strength-ranked top/weakest entries.
@@ -21,6 +35,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 - Workspace memory rendering now ranks entries by retention strength, not the previous priority/penalty model.
 - Confidence is retained for compatibility but no longer affects retention scoring.
+- Deprecated `safetyCritical` is retained for JSON compatibility but no longer affects retention strength or type-cap behavior.
 - Old or stale-marked memories are no longer hard-pruned; they remain stored and only fall out of rendered context through strength and cap competition.
 - Existing duplicate promotion and dedupe paths now reinforce the surviving memory instead of only absorbing the duplicate.
 - Health output now separates stored active memories from rendered candidates to make cap behavior easier to understand.

RELEASE_NOTES.md

@@ -1,12 +1,47 @@
 # Release Notes
 
+## 1.5.1 (2026-04-30)
+
+### Evidence Loop and Explainability
+
+This release adds an evidence-based audit trail for memory lifecycle events and user-facing diagnostics for understanding why memories are rendered, promoted, or rejected.
+
+> **Evidence before sublimation.** Every memory decision can be traced.
+
+### What Changed
+
+- **Evidence log**: extraction, promotion, reinforcement, render, and storage events are now recorded in a per-workspace `events.jsonl` with 90-day retention and 5000-event cap.
+- **User explainability**: `memory-diag explain` shows per-memory render status with strength, reasons, and evidence. `memory-diag trace --memory <id>` shows the full lifecycle history.
+- **Machine-readable diagnostics**: `memory-diag health --json` outputs structured `MemoryDiagJSON` for scripting.
+- **Calendar-day reinforcement gate**: reinforcement now requires distinct UTC calendar days, preventing repetitive-task gaming that could inflate a memory's strength within a single day.
+- **SafetyCritical deprecation complete**: the `safetyCritical` field no longer affects retention strength or type-cap bypass. All memories fade by the same rules.
+- **Retention module extraction**: retention constants and calculations moved to `src/retention.ts` for cleaner separation.
+
+### Privacy
+
+- Evidence text previews are credential-redacted. Memory content is stored as truncated hashes, never in full.
+- Diagnostics default to redacted output. `--raw` is available for maintainers.
+
+### Upgrade Notes
+
+- No configuration changes required.
+- Existing workspace memory files remain compatible.
+- Evidence logs are created automatically; no migration needed.
+
+### Validation
+
+- `npm run typecheck`
+- `npm test` — 271 tests passing
+
+---
+
 ## 1.5.0 (2026-04-29)
 
 ### Retention Decay Model
 
 This release changes workspace memory retention from hard stale pruning and additive priority scoring to a strength-based decay model.
 
-Think of it like a forgetting curve: memories fade over time, but important, reinforced, and safety-critical memories decay slower. Weak entries fall out of rendered prompt context by cap competition, not hard deletion.
+Think of it like a forgetting curve: memories fade over time, but important and reinforced memories decay slower. Weak entries fall out of rendered prompt context by cap competition, not hard deletion.
 
 > **Memory should fade, so the agent can keep learning.**
 > Important memories decay slower, but every memory must leave room for newer project reality and avoid long-term memory pollution.
@@ -27,10 +62,10 @@ Think of it like a forgetting curve: memories fade over time, but important, rei
 ### What Changed
 
 - **Strength-based retention**: workspace memory now uses exponential decay: initial strength × age decay.
-- **Better initial strength**: type, source, user importance, and safety-critical status now determine how strong a memory starts.
+- **Better initial strength**: type, source, and user importance now determine how strong a memory starts.
 - **No confidence scoring**: confidence remains in stored data for compatibility, but it no longer affects retention ranking.
 - **Type caps**: rendered workspace memory now caps feedback, decisions, project facts, and references separately so one type cannot monopolize all 28 slots.
-- **Safety-critical protection**: safety-critical entries get stronger retention and are exempt from per-type caps, while still competing under the global rendered cap.
+- **Deprecation:** `safetyCritical` field no longer affects retention strength or type-cap bypass. All system memories now fade according to the same rules. Safety rules belong in user-controlled `agent.md` files, not in system memory.
 - **Dormant-aware age**: after 14 inactive days, additional dormant workspace time counts at 0.25x so paused projects do not forget too aggressively.
 - **Reinforcement**: repeated matching memories reinforce the survivor and slow future decay, with same-session and one-hour guards to avoid accidental spam.
 - **No hard stale pruning**: old or stale-marked memories are no longer automatically dropped by age; they lose rendered space only through cap competition.

docs/architecture.md

@@ -109,14 +109,14 @@ Retention then decides which active memories are rendered into prompt context. I
 strength = initialStrength * 2 ** (-effectiveAgeDays / effectiveHalfLifeDays)
 ```
 
-Initial strength is based on memory type, source, optional user importance, and safety-critical status. Confidence remains stored for compatibility but is not part of retention scoring.
+Initial strength is based on memory type, source, and optional user importance. Confidence remains stored for compatibility but is not part of retention scoring.
 
 Rendered candidates are selected in this order:
 
 1. Exclude `status: "superseded"` entries.
 2. Compute current retention strength.
 3. Sort by strength descending.
-4. Apply per-type caps, with safety-critical entries exempt from type caps.
+4. Apply per-type caps.
 5. Keep the top 28 rendered entries under the workspace memory character budget.
 
 Default type caps:
@@ -132,6 +132,10 @@ The type-cap total is 34, intentionally above the global 28-entry cap. These are
 
 Dormant workspaces age more slowly: after 14 inactive days, additional dormant time counts at 0.25x for retention decay. Repeated duplicate memories reinforce the surviving entry and slow future decay, but same-session and under-one-hour repeats do not stack reinforcement.
 
+### Safety-Critical Deprecation
+
+The `safetyCritical` field on `LongTermMemoryEntry` is deprecated as of the retention v1.5.1 model update. It no longer affects retention strength or type-cap bypass. The field is preserved in the type definition for backward compatibility with existing workspace memory JSON files, but has no active behavior. Safety rules should be maintained in user-controlled files such as `agent.md` rather than in system memory.
+
 ### System Prompt Injection
 
 Workspace memory is injected at the top of every message:

docs/configuration.md

@@ -34,7 +34,7 @@ const WORKSPACE_DORMANT_AFTER_DAYS = 14;
 const DORMANT_DECAY_MULTIPLIER = 0.25;
 ```
 
-Initial strength uses type, source, user importance, and safety-critical factors. Confidence is stored for compatibility but is not used for retention scoring.
+Initial strength uses type, source, and user importance factors. Confidence is stored for compatibility but is not used for retention scoring.
 
 Rendered type caps prevent one type from filling all workspace memory slots:
 
@@ -45,7 +45,7 @@ Rendered type caps prevent one type from filling all workspace memory slots:
 | `project` | 8 |
 | `reference` | 6 |
 
-Safety-critical memories are exempt from type caps but still compete under the global `maxEntries` limit. Old or stale-marked memories are not hard-pruned by age; they lose rendered space through strength and cap competition.
+Old or stale-marked memories are not hard-pruned by age; they lose rendered space through strength and cap competition. The deprecated `safetyCritical` field is preserved for compatibility but no longer affects strength or type caps.
 
 ## Hot Session State Limits
 

package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-working-memory",
-  "version": "1.5.0",
+  "version": "1.5.1",
   "description": "Three-layer memory architecture for OpenCode with workspace memory and hot session state",
   "type": "module",
   "main": "index.ts",