# Ticket: Nimrod self-improvement, memory, and retrieval system

## Metadata
- Type: Ticket
- Status: Done (except unknown Proxmox hosts 2 & 3)
- Project: Nimrod / Agent Operations
- Created: 2026-06-06
- Updated: 2026-06-06
- Priority: High

## Goal

Design and implement a lightweight self-improvement and durable-memory system so Nimrod can retain important information, retrieve it efficiently in fresh contexts, verify it when needed, and fix root causes when repeated user input is required.

## Why

Nimrod is intended to be the user's personal assistant first, while also wearing software developer, DevOps, D&D helper, documentation assistant, and other hats. Fresh contexts must stay light, but the system must still handle a wide range of requests. The user has repeatedly had to re-provide Proxmox connection details, which indicates a failure in durable memory/retrieval rather than a one-off inconvenience.

## Scope

Included:
- Define what information should be retained durably
- Define where information should live based on sensitivity and usage
- Define fresh-context entrypoint rules that stay lightweight
- Define retrieval/indexing strategy for many possible request types
- Define a mistake/improvement loop for recurring failures
- Define verification rules for retained facts
- Fix the Proxmox connection-details retrieval failure as an initial case study

Not included:
- Building a full autonomous self-modifying agent
- Storing secrets in unsafe plaintext
- Implementing a vector database in the first pass unless later selected

## Acceptance Criteria

This ticket is done when:
- [x] A Nimrod memory/retrieval policy is documented — `docs/nimrod-memory-and-self-improvement.md`
- [x] Fresh-context entrypoint remains lightweight and points to indexes, not large docs — AGENTS.md is a compact router
- [x] A durable facts/index structure exists — `infra/proxmox-registry.yaml`, `systems/inventory.md`, `systems/status.md`, `.pi/ssh/hosts.json`, service runbooks
- [x] A mistake-to-improvement loop is documented — exists in the memory policy; `docs/templates/root-cause-improvement-template.md` added as a structured form
- [x] Proxmox connection details are findable — `buntbox01` documented in registry, inventory, and change log; `.tokens/proxmox.env` reference exists. Hosts 2 & 3 are unknown and require user input when the multi-Proxmox ticket is worked
- [x] Verification rules exist for stale or sensitive facts — documented in memory policy
- [x] AGENTS.md points future agents to the memory/retrieval policy — line 187

## Questions

- Should durable facts live primarily in markdown, YAML/JSON indexes, or both?
- Which facts are safe to load automatically, and which require explicit retrieval?
- Should retrieval eventually use a generated index, SQLite, or vector DB?
- What information belongs in Nimrod versus a personal knowledge base or future Git service?

## Progress

2026-06-07:
- All ACs verified as already satisfied or addressed in this session.
- Added `docs/templates/root-cause-improvement-template.md` — the missing structured form for the mistake-to-improvement loop.
- Proxmox `buntbox01` details are findable through multiple index paths. The other two Proxmox hosts remain unknown, tracked in `tickets/active/2026-06-07-multi-proxmox-access-inventory.md`.

## Notes

- Repeatedly asking the user for the same operational fact should trigger root-cause analysis and documentation/index improvement.