← Memova.aiCONTENT HISTORY
WHAT CHANGED
Update to Memova.ai
Snapshot Oct 24, 2026 · 13:10 UTC · version 1.15.1
Collection source: downloaded plugin package.
First saved snapshot
No earlier snapshot is available to establish a change.
Save Memova.ai and check future changes in Following.
Up to 3 plugins free · no card required.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Use when the user explicitly asks Memova/Codex to diagnose, validate, repair, or troubleshoot a Memova Knowledge Base V2, V3, or V4 managed root, iCloud folder binding, or meeting-to-vault sync write problem.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 469
}
],
"name": "memova-vault-diagnose",
"skill_md_contents": "---\nname: memova-vault-diagnose\ndescription: Use when the user explicitly asks Memova/Codex to diagnose, validate, repair, or troubleshoot a Memova Knowledge Base V2, V3, or V4 managed root, iCloud folder binding, or meeting-to-vault sync write problem.\n---\n\n# Memova Vault Diagnose\n\nUse this skill only when the user explicitly asks to diagnose, validate, repair, or troubleshoot a\nMemova Knowledge Base V2/V3/V4 managed root or a meeting-to-vault sync failure.\n\n## Operating Rules\n\n- On every invocation, run the plugin version check from the plugin root before diagnosis:\n\n ```bash\n python3 plugins/memova/scripts/version_check.py\n ```\n\n If it returns `should_remind: true`, show the message and continue diagnosis. If the check fails\n or returns no reminder, continue silently. Never run the upgrade command without explicit user\n confirmation.\n- Prefer deterministic helper scripts first. Use Codex judgment to explain ambiguous selected\n folders, likely iOS binding mistakes, and safe repair choices.\n- Do not read full private notes or recurse through an entire existing vault unless the user asks.\n Lightweight tree inspection is enough for setup and binding diagnosis.\n- Never write repairs before the user approves the exact target path and repair plan.\n- Do not overwrite user-authored files. Only missing folders/files and `_memova` machine files may be\n created or overwritten after approval.\n- Never store or echo secrets, OAuth tokens, raw credentials, or full private note contents.\n- Diagnosis/local validation is not setup completion. Do not say a knowledge-base setup is complete\n or mark the setup reminder complete from this skill; only the setup workflow may do that after\n backend `complete_knowledge_base_setup` succeeds.\n\n## Default Diagnosis Workflow\n\n1. Ask for the Mac path if the user has not provided one. The path can be either a new Memova\n knowledge-base root or the root-level `Memova/` managed sub-knowledge-base inside an existing\n user vault.\n2. From the `memova-vault-setup` skill directory, run validation first:\n\n ```bash\n python3 scripts/diagnose_memova_vault.py --path \"<path>\"\n ```\n\n Add `--allow-non-icloud` only when the user knowingly chose a local folder instead of iCloud.\n For V3/V4 repair, retrieve the current backend setup or repair package and add\n `--setup-json \"/tmp/memova-setup.json\" --repair-plan`; do not generate V3/V4 repair files from\n local plugin templates. V2 may use `--repair-plan` without a setup package for compatibility.\n3. Summarize:\n - whether the folder validates,\n - whether it appears to be a new Memova vault or an embedded `Memova/` managed root,\n - missing manifests/state files,\n - candidate `Memova/` binding paths if the selected folder looks like an existing vault.\n4. If the report contains a repair plan, explain only the operations with status `create` or\n `overwrite`. Ask for explicit approval before writing.\n5. After approval, run:\n\n ```bash\n python3 scripts/diagnose_memova_vault.py \\\n --path \"<path>\" \\\n --setup-json \"/tmp/memova-setup.json\" \\\n --repair-plan \\\n --apply-repair \\\n --confirm-repair\n ```\n\n Add `--overwrite-machine-files` only when repairing broken `_memova` JSON and the user approved\n overwriting machine files.\n6. Validate again and report the template version, final manifest ids, and\n `memova_input_root_relative_path`.\n\n## iOS Binding Checks\n\nWhen the user is trying to connect the iOS app to the folder:\n\n- Tell iOS to validate `_memova/manifest.json` in the selected Memova managed root.\n- If the user selected a full new Memova vault, the selected folder itself should contain\n `_memova/manifest.json`.\n- If the user selected an existing vault integration, the iOS app can authorize the existing vault\n root and resolve `Memova/_memova/manifest.json` through `ios_folder_binding_hints`.\n- Compare `input_root_manifest_id`, `vault_template_version`, and\n `memova_input_root_relative_path` with the setup result returned to Memova.\n- If `ios_folder_binding_hints` is available from the backend binding, iOS should use its\n `candidate_manifest_paths` against the user-authorized folder before falling back to a shallow\n local search.\n\n## Meeting Sync Troubleshooting\n\nFor meeting-to-vault write failures:\n\n- First validate the Memova managed root with `diagnose_memova_vault.py`.\n- If the folder validates, inspect the sync package file paths and hashes. The iOS app writes package\n `files[].relative_path` below the Memova managed root and then reports completion or failure to\n Memova.\n- Treat hash mismatches, missing local permissions, iCloud unavailable/offline state, and stale setup\n bindings as separate causes. Ask the user for the failing path or iOS error if Codex cannot infer\n the cause from the report.\n"
}SHA-256 of public snapshot: f8ec0174e770ea027270b869d4ffad93038ffbd9bb5ffd12e6bf324f32ac706a