v1.5.5

Hot State Rendering Health

Replace blunt .slice(0, maxRenderedChars) prompt truncation with a section-aware greedy line accumulator that fits whole lines and suppresses empty sections.

Good rendering is selective too. If a section doesn't fit, omit it — don't cut it in half.

What Changed

• Whole-line rendering: hot session state prompt no longer truncates mid-line. A greedy accumulator fits complete lines and stops when the next line would exceed the 700-char budget.
• Header-only sections suppressed: a section heading is only rendered if at least one entry fits alongside it.
• Render accounting: accountHotSessionStateRender() returns prompt, omitted items, and char budget for future v2 diagnostics.
• Two-layer omission model: section caps (section_cap) trim per-type overflow first, then char budget (char_budget) trims anything that doesn't fit.
• Backward-compatible wrapper: renderHotSessionState() delegates to the accounting function.

Docs Fixes

• Active-file ranking formula corrected in docs/configuration.md: now matches actual implementation — ACTION_WEIGHT[action] + count * 3 with weights edit 50, write 45, grep 30, read 20.
• Injection order clarified in README: system-prompt positions depend on whether workspace memory state is available.

Not Included Yet

• Evidence events for omitted items deferred to v2, pending a memory-diag consumer.

Validation

• npm run typecheck — TYPECHECK_PASS
• npm test — 356 tests passing

v1.5.4

v1.5.4 — Memory-Diag CLI Surface Cleanup

What changed

• Removed legacy CLI aliases: health, quality, rejections, disappearances, and trace are no longer recognized. They return a plain Unknown subcommand message with no migration redirect, to avoid carrying compatibility debt.
• Centralized command metadata: All command definitions now live in command-metadata.ts as the single source of truth.
• Official commands unchanged: status, rejected, missing, explain continue to work as before.
• Hidden maintainer commands preserved: coverage and audit remain available with neutral maintainer-only notices.
• Removed cleanup:workspaces script: The npm script is gone from package.json; the dev tool source file is preserved for internal use.

Test evidence

• 347 tests passing
• Typecheck clean
• All CLI smoke checks verified
• Independent phase verification: PASS (15/15 checks)
• Comprehensive code review: APPROVE

Migration

If you were using legacy aliases:

Old alias	Use instead
health	status
quality	status --verbose
rejections	rejected
disappearances	missing
trace <id>	explain --memory <id>

v1.5.3

Published Memory Diagnostics CLI

This release makes the read-only workspace memory diagnostics CLI available as the package binary memory-diag, with user-facing commands for checking memory health and understanding why memories are rejected, missing, shown, or hidden.

Good memory is selective memory — and diagnostics should explain the selection.

What Changed

• Published CLI bin: run diagnostics with npx --package opencode-working-memory memory-diag or memory-diag status.
• User-facing commands: status, rejected, missing, and explain <memory-id> are documented as the supported public workflow.
• Legacy compatibility: existing maintainer and legacy commands remain accepted with deprecation notices where applicable.
• Cleaner CLI architecture: the former monolithic diagnostics script is now split into focused command, model, formatter, and utility modules.
• Faster diagnostics: evidence grouping avoids repeated per-memory evidence queries in snapshot diagnostics.
• Cleaner failures: top-level CLI error handling now reports usage and unexpected command errors without noisy stack traces.
• Docs alignment: README and configuration docs now use package-qualified npx commands to avoid resolving an unrelated package named memory-diag.

Requirements

• Node.js >=22.6.0 is now required because the published diagnostics binary runs TypeScript through Node's --experimental-strip-types support.

Validation

• npm run typecheck — TYPECHECK_PASS
• npm test — 358 tests passing, TEST_PASS

v1.5.2

Summary

• Close capacity-driven workspace-memory disappearance evidence gaps with storage-level removal events.
• Add focused memory inspection CLI surfaces: quality, coverage, disappearances, and rejection quality review.
• Harden memory quality decisions, rejection scoping, retention clock backfill, and verification sentinels.

Verification

• npm test -> TEST_PASS (290 passing)
• rtk npm run typecheck -> TYPECHECK_PASS
• CLI smoke: quality, coverage, disappearances, disappearances --explain, rejections --quality

v1.5.1

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

v1.5.0

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.

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.

  strength
    │
 ██ │╲____   reinforced: slower decline
    │     ╲______
 ▒▒ │            ╲__ ordinary memory
    │               ╲
    ├ ─ ─ ─ ─ ─ ─ ─ ─╲─ dynamic cap competition zone
 ░░ │                 ╲  easier for new memories to replace
    │                  ↑ still stored, not deleted
    └──────────────────────────────→ time / sessions

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.
• 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.
• 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.
• Calibrated prompt budgets: observed rendered output was typically under ~2000 characters for workspace memory and ~500 characters for hot session state, so defaults were reduced to 3600 and 700 characters to keep overhead lower while retaining buffer.
• Clearer health output: memory-diag health now reports stored vs rendered counts, type caps, global cap overflow, dormancy, retention monitoring, and strength-ranked top/weakest entries.

Why This Helps

• User preferences and explicit memories are less likely to disappear just because inferred project facts are newer.
• Feedback, decisions, project facts, and references share prompt space more fairly.
• Returning to an old workspace is less punishing because dormant time decays more slowly.
• Maintainers can see why memories are rendered or capped instead of guessing from a single active-memory count.
• Stale entries can fade out of prompt context without destructive cleanup.

Diagnostics

Maintainers can inspect retention behavior with:

bun scripts/memory-diag.ts health

The health output now includes sections like:

Stored active memories: 28
Rendered candidates: 20

By type:
  feedback  stored=17  rendered=10  typeCap=10
  decision  stored=11  rendered=10  typeCap=10

Retention caps:
  type-capped entries: 8
  global-cap overflow: 0

Dormancy:
  dormant discount active: no

Retention monitoring:
  high_importance_ratio: 0.0% (alert > 30%)

Not Included Yet

• Delete tombstones are not implemented in this release.
• Explicit supersedes chain enforcement is still deferred.
• Hot/warm/cold tiered storage remains future work.

Upgrade Notes

• No configuration changes required.
• Existing workspace memory files remain compatible.
• Existing entries without a retentionClock fall back safely to existing timestamps.
• The OpenCode config entry stays the same:

{
  "plugin": ["opencode-working-memory"]
}

Validation

• npm run typecheck
• npm test — 238 tests passing
• bun scripts/memory-diag.ts health

v1.4.0

Memory Quality Cleanup

This release makes OpenCode Working Memory more selective about what becomes long-term memory, while keeping existing memories safe.

The biggest change is a conservative cleanup migration: v1.4.0 can automatically archive obvious noise, but it avoids broad cleanup rules that might remove useful project decisions, API facts, user preferences, or architecture notes.

What This Improves

• Cleaner future memories: Compaction now has stricter guidance, so it should save fewer low-value memories and focus on durable facts.
• Safer historical cleanup: Existing memories are only superseded when they match high-confidence garbage patterns, not just because they fail a soft heuristic.
• Better recovery path: Every automatic migration cleanup is written to a local audit log, so archived entries can be inspected and restored.
• More evidence for future tuning: Rejected compaction candidates are logged locally, making future quality-rule changes data-driven instead of guesswork.
• Less test pollution: Tests now use isolated temporary storage, and a cleanup command can quarantine old test/temp workspace residues.

What Gets Cleaned Up

The one-time 2026-04-28-quality-cleanup migration may supersede active source: "compaction" memories when they are clearly noisy, such as:

• Progress snapshots like completed waves, phases, or test-count status
• Raw errors, stack traces, commit/CI snapshots, or temporary status notes
• Active-file snapshots and path-heavy entries that are easy to rediscover
• Code/API signatures that should not be stored as durable memory
• Empty entries

The migration marks entries as status: "superseded"; it does not delete them.

What Is Protected

The migration does not supersede memories whose only issue is a soft heuristic failure such as bad_feedback or bad_decision.

This protects declarative but useful memories such as:

• Product or release rules
• API endpoint facts
• Architecture decisions
• User workflow preferences
• Project-specific implementation constraints

Explicit and manual memories are also protected.

Local Logs and Recovery

Migration audit log:

~/.local/share/opencode-working-memory/migration-logs/2026-04-28-quality-cleanup.jsonl

Extraction rejection log:

~/.local/share/opencode-working-memory/extraction-rejections.jsonl

If a useful memory is archived, inspect the migration audit log and restore it by changing that entry back to status: "active" in the workspace's workspace-memory.json.

Workspace Residue Cleanup

If old test/temp workspace stores already exist locally, inspect them first:

npm run cleanup:workspaces -- --dry-run

To move definite temp/test residues into quarantine instead of deleting them:

npm run cleanup:workspaces -- --quarantine

Unknown missing-root workspaces are skipped by default.

Upgrade Notes

• No configuration changes required.
• Existing workspace memory files remain compatible.
• The OpenCode config entry stays the same:

{
  "plugin": ["opencode-working-memory"]
}

Validation

• npm test — 212 tests passing
• npm run typecheck
• CI passed in #4

v1.3.3

Fixed

• Added atomic cross-process storage writes with stale-lock recovery and heartbeat refresh to prevent concurrent memory-file corruption.
• Scoped pending-memory promotion by owner/session so global unowned cleanup no longer removes active owned entries.
• Retained source-aware pending memories until they are actually promoted, absorbed, superseded, or rejected.
• Persisted load-time security redaction and expanded Bearer-token redaction to reduce secret retention risk.
• Hardened workspace normalization, cache bounds, rejected-entry retention, and session cleanup behavior.

v1.3.2

v1.3.2 — CI Compatibility Patch

• Fixed the compatibility workflow so dependency installation works without a committed lockfile.
• Moved compatibility CI to Node 24 so TypeScript-stripping tests run correctly.
• No runtime or storage changes.

v1.3.1 — Security and Reliability Patch

This patch keeps the v1.3 memory-consolidation model intact while tightening storage safety, compatibility checks, and repository-agnostic dedupe behavior.

What Changed

• Bounded pending journal: pending memories are capped at 50 entries and pruned after 30 days.
• Security hardening: workspace memory candidates now reject indirect prompt-injection attempts, and redaction covers broader token, secret, credential, auth, and private-key labels.
• Compatibility coverage: plugin capability tests and weekly OpenCode plugin API compatibility CI help catch hook drift before release.
• Repo-agnostic dedupe: long-term memory dedupe no longer depends on hardcoded project-specific topic rules; project/reference memories use generic URL/path identity plus exact canonical matching.
• Clearer limitations: README and changelog now document compatibility, best-effort secret redaction, working-memory scope, plugin ordering, and multi-process write boundaries.

Thanks

• Thanks @StevenChoo for the security hardening contribution in #3.

Upgrade Notes

• No user migration is required.
• Existing workspace memory and pending journal files remain compatible.
• The OpenCode config entry stays the same: "plugin": ["opencode-working-memory"].

v1.3.0 - Better Memory Consolidation

1.3.0 (2026-04-27)

Better Memory Consolidation

This release makes OpenCode Working Memory smarter about what happens to saved memories after compaction. Instead of treating every pending memory as simply "kept" or "not kept", it now understands four outcomes:

• Promoted — a new memory was saved to workspace memory.
• Absorbed — the memory was a duplicate of something already remembered.
• Superseded — a newer same-topic decision or preference replaced an older one.
• Rejected — the memory was stale, noisy, or over the workspace memory limit.

What This Improves

• Fewer repeated pending memories: duplicate or superseded memories no longer keep coming back for promotion.
• Cleaner long-term memory: old same-topic decisions are replaced more predictably.
• Safer promotion accounting: pending memories are only cleared when the final normalized workspace memory confirms what happened to them.
• More useful compaction output: the compaction prompt now includes clearer examples of what should and should not become durable memory.

Also Included

• Memory quality regression fixtures: 5 examples that should be kept and 7 noisy examples that should be rejected.
• Fix for session.deleted session ID extraction so cleanup and promotion use the same event parsing path.
• Fix for active-vs-superseded promotion behavior: archived superseded entries no longer block a fresh active memory.
• README and architecture documentation updates.

Upgrade Notes

• No user migration is required.
• Existing workspace memory files remain compatible.
• The OpenCode config entry stays the same:

{
  "plugin": ["opencode-working-memory"]
}

Tests

• 135 tests pass.