Tutorial 11 walked one maintenance pass end to end. This tutorial turns that into a routine you can re-run for the life of a store — the thing you reach for after a large import, a hierarchy change, or a stretch where retrieval started feeling unreliable.
The loop is four steps: audit, decide, repair, verify. The order carries the whole discipline. Auditing before deciding stops you from fixing the wrong thing; verifying with the same read that exposed the problem is what proves the repair actually worked rather than merely ran.
As in Tutorial 11, finding nothing to repair is a valid result — and here it will be common, because you may have already repaired this store once.
[loom_demo] store is configured and reachable. Everything below is scoped to it.[kanban] or any other store.Expect this to take about twenty minutes.
[loom_demo] for this session, confirm its description, and do not change persistent configuration.[loom_demo] for this session and left persistent configuration unchanged.[loom_demo] in read-only mode. Check for duplicate or near-duplicate categories, conflicting current facts, missing project scope, missing author attribution, unfinished Roadmap items, and stale work records. Group findings by severity, cite exact record IDs and types, and do not change anything.Keep this report as the before-state.
[loom_demo] records for missing or inconsistent project and author edges. Propose a correction only when the intended existing target is explicit in record history; never infer it from this disposable repository's Git identity.If you ran Tutorial 11, expect this step to be a no-op. That tutorial's §3 targets this same Roadmap in this same store, so if it closed there, the item is already closed and the correct outcome now is to say so — not to close it twice. Retrieve the existing receipt instead and confirm the item has left the open-work view. Recognising already-done work is the exercise.
[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 with no mutation.If closure occurred, retrieve the receipt and confirm the item left the open-work view. Otherwise confirm that it remains open or absent.
[loom_demo][loom_demo]. Classify them as open, completed, cancelled, awaiting a decision, or unclear from the available evidence. Do not query [kanban], do not use Kanban events, and do not change anything.[loom_demo], treats age as context rather than proof, and reports exact IDs and types.[loom_demo]; if it contains no task-like records, the result is empty. No changes were made.[loom_demo] health checks as the baseline. List mutations actually made (possibly none), every verification result, preserved history, unresolved items, and follow-up steps. Do not report a repair that did not occur.Use this prompt after a large import, hierarchy change, or retrieval problem:
[loom_demo] for this tutorial run, audit store health first. Show evidence for duplicate categories, conflicting current facts, scope and author problems, incomplete Roadmap lifecycles, and stale work. Make no changes until I approve a bounded repair; preserve history and repeat every exposing read afterward.Every step reports no changes. Expected, especially straight after Tutorial 11. A clean store produces a clean audit. Zero mutations across all eight steps is a passing run, not a broken one.
A merge in §2 would collapse two categories that only look alike. Reject it. Consolidation is by shared meaning, not similar spelling — two categories spelled almost identically can be genuinely distinct, and a merge that loses that distinction is not recoverable by re-running the audit.
You cannot tell whether a newer fact negates, disputes, or supersedes an older one. That ambiguity is itself the finding. Leave it unresolved and list it. §3 asks you to explain which relationship applies; if you cannot, the evidence is not sufficient to repair it yet.
The agent wants to fill in a missing author or scope from your Git identity. Decline. §4 is explicit that the intended target must be present in the record's own history — inferring it from whoever happens to be running the tutorial invents attribution that will later read as fact.
The before-and-after reads in §7 disagree with what you were told was repaired. Trust the reads. That is exactly why the loop repeats the same query rather than a fresh one.