Cubox

# card delete — Dry Run Policy

Delete one or more cards by ID.

```bash
cubox-cli delete --id CARD_ID [--id ID2,...] [--dry-run]
```

## Flags


| Flag          | Description                                                    |
| ------------- | -------------------------------------------------------------- |
| `--id ID,...` | Card IDs to delete (comma-separated, required)                 |
| `--dry-run`   | Preview which cards would be deleted without actually deleting |


## Output

Returns: `{ "dry_run": bool, "count": N, "cards": [...], "message": "..." }`

- When ≤ 3 cards: `cards` array includes `id`, `title`, `url` fetched from server.
- When > 3 cards: `cards` is omitted; only `count` is shown (avoids heavy per-card API calls).

## Dry Run Policy for AI Agents

Deleted items stay in the user's "Recently Deleted" folder for 30 days before permanent removal, but agents must still treat deletion as destructive.

1. **Always** run with `--dry-run` first before any real deletion.
2. Present the dry-run result to the user and ask for explicit confirmation.
  - ≤ 3 cards: show the card titles returned by dry-run.
  - > 3 cards: tell the user the count (e.g. "Will delete 25 cards").
3. Only after the user confirms, run again without `--dry-run` to perform the actual deletion.
4. Never skip the dry-run step.

## Example workflow

```bash
# Step 1: preview
cubox-cli delete --id 7435692934957108160,7435691601617225646 --dry-run
# Step 2: show user the preview, ask "Delete these 2 cards?"
# Step 3: if confirmed, execute
cubox-cli delete --id 7435692934957108160,7435691601617225646
```



# RAG vs Keyword Search — Decision & Workflow

This reference defines how to choose between `card list --keyword` and `card rag --query`, and how to handle results progressively. **Follow these rules whenever the user asks you to find, search, or retrieve bookmarks from Cubox.**

## Step 1 — Choose the right search method


| User intent                                           | Method                     | Example                                                                                 |
| ----------------------------------------------------- | -------------------------- | --------------------------------------------------------------------------------------- |
| Exact term, title fragment, domain, known phrase      | `card list --keyword`      | "find my bookmarks from csdn.net", "search for 'React hooks'"                           |
| Conceptual question, topic exploration, fuzzy intent  | `card rag --query`         | "articles about building REST APIs with auth", "what did I save about LLM fine-tuning?" |
| Browse / filter by metadata (folder, tag, star, time) | `card list` (with filters) | "show starred cards from last week", "list cards in folder X"                           |


**Decision rules:**

- If the user provides 1–3 specific words that are clearly keywords → use `card list --keyword`.
- If the user describes an intent, asks a question, or uses a phrase that would benefit from semantic understanding → use `card rag --query`.
- If in doubt, prefer `card rag` — it is a superset that handles both precise and fuzzy queries well.
- You can combine: first `card rag` for discovery, then `card list --keyword` or `card list` with filters to narrow down.

## Step 2 — Refine the query before sending

Before calling `card rag --query`, **you must refine the user's raw input** into a better query:

1. **Extract core intent** — strip conversational filler ("hey can you", "I think I saved", "帮我找找").
2. **Expand with context** — if the user's wording is too short or vague, enrich with synonyms or related terms that better capture the intent. For example:
  - User: "database image upload" → Query: "Java implement database image upload and display on frontend"
  - User: "那篇关于网红的文章" → Query: "网红 流量 社会责任 互联网"
3. **Preserve language** — keep the query in the same language the user used. Do not translate unless asked.
4. **Keep it concise** — t