{"id":43413,"plugin_id":"plugin_asdk_app_6a1bf0c36ea8819192770944990d8b72","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-24T13:10:33.665Z","digest":"f8ec0174e770ea027270b869d4ffad93038ffbd9bb5ffd12e6bf324f32ac706a","against":null,"payload":{"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"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}