This addresses the security audit findings around destructive path handling, sensitive data leaking into the WAL, overly permissive query sanitization, and missing validation on MCP read filters. The changes tighten deletion guardrails and bring read-path validation in line with existing write-path protections.

• Destructive operation guardrails

  • migrate and repair now require the target path to contain chroma.sqlite3 before any destructive action.
  • Both commands now prompt before replacing/removing palace data, with --yes available for explicit non-interactive confirmation.
  • repair also validates any pre-existing backup path before deleting it.

• WAL redaction coverage

  • Expanded WAL redaction to cover actual sensitive payload fields used by tools:
    • content
    • entry
    • query
    • text
    • document
    • existing preview fields

• Query sanitization tightening

  • Reduced MAX_QUERY_LENGTH from 500 to 250.
  • Improved trimming so long contaminated inputs preserve the likely search intent while handling wrapping quotes more precisely.

• MCP read-side input validation

  • Applied sanitize_name-style validation to read/search filters passed through MCP tools, including wing, room, and tunnel filter inputs.
  • Invalid filter values now fail fast instead of being passed to the storage/query layer.

Example of the new destructive-path safety check:

if not contains_palace_database(palace_path):
    print(f"\n  No palace database found at {db_path}")
    return

if not confirm_destructive_action("Repair", palace_path, assume_yes=args.yes):
    return