Update to Memory Keeper

{
  "description": "Use when about to claim persistent project work is complete, done, fixed, organized, saved, synchronized, updated, cleaned, migrated, or successfully written.",
  "included_files": [
    {
      "relative_path": "references/verification-gates.md",
      "size_in_bytes": 1530
    }
  ],
  "name": "verifying-persistent-work",
  "skill_md_contents": "---\nname: verifying-persistent-work\ndescription: Use when about to claim persistent project work is complete, done, fixed, organized, saved, synchronized, updated, cleaned, migrated, or successfully written.\n---\n\n# Verifying Persistent Work\n\n## Iron law\n\n**No persistent success claim without fresh authoritative evidence from the actual persistent surface after the last mutation.**\n\nA successful write call, old test run, remembered state, temporary `/mnt/data` artifact, or search hit alone is insufficient.\n\n## Gate\n\n1. identify evidence for every applicable requirement;\n2. run relevant technical verification freshly;\n3. obtain **authoritative evidence** from a direct filesystem read/stat/hash or **provider-native read/list** of the exact persistent item **after the last mutation**;\n4. verify owning canonical memory and parent routing where applicable;\n5. verify references/pointers and absence of competing active canons;\n6. compare observed final state with requested target.\n\nA **search/index result alone is insufficient** to prove destructive absence, exact final identity, or completion when direct read/list is available; indexes can lag. Use search for discovery, then verify directly.\n\nIf any gate is unchecked or fails, state **NOT COMPLETE**. Operational repair may use `recovering-persistent-work` only within its fingerprint and transaction budgets. Verification itself must not create an unbounded reverify/recover loop.\n\nUse `references/verification-gates.md` for the checklist. Do not use “done”, “fixed”, “saved”, “organized”, “clean”, or “synced” until it passes.\n"
}