A memory store that nobody maintains slowly stops being trustworthy. Plans stay open after the work shipped, two facts end up disagreeing, a reminder fires long after it mattered. None of that announces itself — the store just quietly gets less useful, and you start double-checking it, which defeats the point of having it.
This tutorial is a maintenance pass you can run repeatedly and safely. The discipline it teaches is the important part: audit first, cite exact records, and change only what the evidence supports.
The single most useful idea here is one that feels wrong at first — finding nothing is a successful run. A maintenance pass that reports no problems and changes nothing has done its job. A pass that invents work to look productive has actively damaged your store.
loading a store and reading facts back.
[loom_demo] store is configured and reachable. Everything below is scoped to it and touchesno other store.
loom-maintenance skill is installed; it supplies the exact mechanics for each step.Expect this to take about fifteen minutes. Steps 2 through 5 may legitimately make no changes at all.
loom_demo the session defaultloom_demo and make it the default for this session only. Confirm the effective session default, and do not edit ~/.loom/stores.toml.[loom_demo] and changes only this session's routing.loom_demo is now the default for this session. Persistent configuration was not changed.loom-maintenance skill in audit-only mode against [loom_demo]. Check for duplicate or unused categories, conflicting current facts, noisy reminders, stale work records, and incomplete plans. Cite exact fact IDs and types. Do not change anything.[loom_demo], treats age as context rather than proof, and reports only evidence-backed findings.[loom_demo]; categories with no finding are empty. No changes were made.[loom_demo] audit, apply only repairs that are unambiguous and supported by cited fact IDs. If no such repair exists, make no changes. Preserve history and repeat the same reads afterward.[loom_demo] was left unchanged. Ambiguous findings remain listed.The Roadmap below is the one Tutorial 08 created. Closing it here completes a lifecycle that started in Tutorial 08, which is why the evidence bar is high: a plan recorded in one session is being retired in another, by a reader who was not there when it was written.
[loom_demo], look for an exact open Roadmap named document the bundled CSV columns. Close it only if that exact item exists and this disposable repository contains real branch, commit, file, and test evidence. Otherwise report not closed and make no change.not closed and no evidence was invented.[loom_demo], identify any reminders that appear misplaced and describe which relationships a future migration would have to preserve. Do not read or write another store, and do not retire anything.[loom_demo] and inventories the relationships a future, separately approved migration would need.[loom_demo] exposes a project-specific surfacing mount. If it does, propose a slightly more selective planning cutoff and two test prompts, but do not apply it. If it does not, report that this step is unavailable.The audit found nothing. That is a pass, not a failure. [loom_demo] is small and mostly seeded, so an empty report is the expected result on an early run. Re-read §1's takeaway before going looking for something to fix.
The agent proposed a repair you cannot trace to a record. Decline it. Every repair in §2 has to name the fact IDs it rests on. A proposal without citations is a guess, and applying it is how a store starts drifting away from what actually happened.
Step 3 reports not closed. That is usually correct. Closing a plan needs the exact Roadmap item and real branch, commit, file and test evidence in the repository. Missing evidence is a reason to leave it open, never a reason to invent a receipt.
The agent wants to move something to another store. §4 is a preview only. If a step proposes reading or writing a second store, stop — that is outside this tutorial and needs separate approval.
Step 5 reports the optional mount is unavailable. That is a valid outcome and needs no action. The tuning in §5 is genuinely optional.