Module memory 

pnm memory … (and any CLI that adopts it) — CRUD over the VTA’s per-context agent memory (spec/vta/memory/{put,list,delete}/0.1).

A per-context key/value store the hosted agent reads before it answers: plant upserts an entry, recall lists (optionally one key), forget deletes one, and wipe clears the whole context. Each maps onto one of the SDK memory methods.

Two server-side gates gate every operation, and both matter to what an operator sees here:

• Capability — MemoryRead for list, MemoryWrite for put and delete (vta-service/src/trust_tasks/memory.rs). wipe therefore needs both: it lists before it deletes. A reader holds only MemoryRead, so plant / forget / wipe are refused for that role.
• Context access — the isolation boundary. A caller can only touch memory in a context it is permitted to act in, so a context-A agent never reaches context-B memory.

The context is never defaulted at this layer. A super-admin’s access check passes for any context id and the memory tasks do not require the context to exist, so a guessed or mistyped id would read and write a context that is not there — silently, and looking exactly like an empty one. The caller names the context or there is no call.

Functions

cmd_memory_forget

forget → memory_delete for one key.

cmd_memory_plant

plant → memory_put. Upserts value under (context, key); re-planting the same key overwrites the stored value.

cmd_memory_recall

recall → memory_list, optionally filtered to a single key.

cmd_memory_wipe

wipe → list, then memory_delete every key. There is no bulk-delete Trust Task, so this is N round-trips and not atomic. Needs both memory capabilities — MemoryRead for the list, MemoryWrite for the deletes.