# Agent memory lifecycle fixture

This fixture turns a few memory-policy rules into code you can rerun. It keeps
tenant and subject scope ahead of similarity, separates model inferences from
confirmed records, resolves conflicts by source authority before recency, and
tracks deletion across every store named by the application.

The code is deliberately small. It is a reference boundary, not a storage engine
or a claim that one precedence order fits every product.

## Files

- `memory-record.schema.json` defines the portable record shape.
- `example-records.json` contains synthetic records and one expected selection.
- `memory-lifecycle.ts` implements selection and content-free deletion jobs.
- `memory-lifecycle_test.ts` covers scope, precedence, expiry, supersession, and
  deletion behavior.

## Run

```bash
deno check memory-lifecycle.ts memory-lifecycle_test.ts
deno test --allow-read=example-records.json memory-lifecycle_test.ts
```

The fixture uses no network access, environment variables, or third-party
packages. All identifiers and facts are synthetic.

## Limits

The selector handles one exact field inside one verified scope. It does not
perform semantic retrieval, authorize the caller, encrypt records, or delete
data on your behalf. The application must derive `tenantId` and `subjectId` from
authenticated runtime state before calling it.

Deletion jobs list the stores that must answer, but the fixture does not connect
to those stores. A completed receipt blocks later index events for the same
memory ID; production code should also make memory IDs immutable and retain
tombstones according to its privacy and backup policy.

License: MIT. See `LICENSE-MIT.txt`.