Tutorial 12: Audit and maintain your durmem store

This tutorial combines the former Tutorial 11 maintenance pass with a repeatable audit. It uses one bounded example, not a cleanup sweep. Start with the store-management guide if you need help identifying a store, then return here to practice an evidence-backed decision.

Why this matters

The loop is audit, decide, repair, verify. Maintenance should make the current view more trustworthy, not create work for its own sake. Read the exact record first, decide from evidence, make at most one approved repair, then repeat the read that exposed it. An empty result or a repair that is not justified is a successful no-op.

Before you start

You know how to select a session store and project scope from Tutorial 03,

and how a Roadmap records planned work from Tutorial 08.

This example concerns only the Roadmap document the bundled CSV columns from Tutorial 08, in

project durmem practice notebook in store loom_demo. It does not assert that the item is present or that the work shipped.

Work in the palmerpenguins clone you opened in Tutorial 00; it is the only evidence source.

Keep the audit bounded to that exact Roadmap and that repository. Do not query kanban or another store, use real personal data, or change anything until the evidence and a proposed repair are shown to you.

1. Read the exact record and its evidence

A Roadmap is a plan; its title or age does not prove delivery. A separate Deliverable records what shipped and how it was verified. For this synthetic example, never infer it from this tutorial setup; check the actual branch, commit, file, and test evidence in the palmerpenguins clone. If you cannot locate the exact Roadmap or the repository evidence, leave it unchanged.

YouIn loom_demo, project durmem practice notebook, read the exact current Roadmap document the bundled CSV columns. Show its fact ID, current status, and relevant history. Check the actual local repository for a branch, commit, changed file, and test evidence that demonstrate this work was delivered. Do not mutate the store or repository. If the record or evidence is missing or ambiguous, say so.

AgentThe agent reads only the exact Roadmap and the bounded repository evidence. A commit alone, a remembered claim, or a similar title is not proof that the named work shipped.

Illustrative outputThe report cites the record and evidence actually found, or says the item/evidence was not found. It does not invent IDs, files, tests, or a completed result. If no repair was supported or approved, No changes were made.

2. Decide before repairing

There are three valid outcomes: the exact item is absent; it is already complete; or evidence is insufficient. Each is a no-op. Do not create a receipt to make an incomplete plan look finished.

YouBased only on that evidence, show me a one-item repair proposal and wait for approval. If the exact Roadmap is still open and the branch, commit, file, and test evidence support delivery, propose marking it done and saving a separate receipt. If it is already done, retrieve and verify its existing receipt. If it is absent or not proved delivered, make no change and explain why.

If you approve a supported completion, the Roadmap's Status records that the work is done; the separate Deliverable records the artifact and verification evidence. Neither a guessed result nor a change in the plan is a delivery receipt. If you do not approve, leave both records untouched.

3. Verify the same read

YouIf I approved the repair, reread the same Roadmap and retrieve its receipt. Confirm the status, artifact, and evidence against the before-state. If no repair occurred, repeat the same read and report that nothing changed.

AgentThe agent compares the same exact record and evidence after the proposed action. It reports only observed mutations; no-op and missing-evidence outcomes remain valid.

4. Preview a move without doing one

If the audit suggests moving a fact to another store, list only the source fact IDs and the relationships or target records a future move would need to preserve. Do not read another store, copy records, or retire the source here. A cross-store move is separate work: it needs an explicit destination, a verified copy, and approval before source records are retired.

If something looks wrong

The item is not found or its evidence is incomplete: report that precisely and leave the

store unchanged. Do not invent a Deliverable.

The item is already done: retrieve its existing receipt and verify it; do not close it twice.
A proposed repair has no exact record IDs or evidence: decline it. Ask for the missing information rather than guessing.
The suggested repair is broader than this one item: stop at the bounded audit and propose separate work.

Takeaways

Audit the exact record before deciding; age and a plausible title are not evidence.
Make one smallest repair only after evidence and approval, then repeat the exposing read.
A Deliverable is evidence of shipped work, not a substitute for it.
An empty, already-complete, or unsupported result can correctly produce no change.
Optionally, continue to Tutorial 13 for a separate synthetic personal-memory example.