bookmarks-lifecycle

MUTATING TOOL. Never call until the user has explicitly confirmed the exact item ids and action in the current turn, unless the MCP host has a trusted autonomous-approval mode enabled — silence, "looks good", or an earlier preference is not confirmation. Moves items to `kept` (keep permanently), `watching` (give it 30 more days), or `lapsed` (remove from the attention queue — this never deletes the browser bookmark or the lifecycle record, and is fully undoable via `undo`). From `pending`: keep/watch/drop all allowed. From `watching`: only `keep` (use `undo` to reverse a watch/drop decision instead of re-deciding an item that's already moved on). Anything else comes back as `not-decidable`. This call may first persist lazy expiry/drip housekeeping (see README) even if you only meant to read.

Scan browser bookmarks (via bookmarks-mcp) and merge them into the lifecycle: new URLs land in `inbox` with their real save date persisted; already-tracked ones get reconciled (sources, title). Never deletes a record — a URL missing from every source that was successfully scanned gets `sourceGone: true`, not removed. A source that failed to read (e.g. Safari without Full Disk Access) is never treated as confirming a URL is gone. Check `sourceStatus` in the response before assuming an empty result means nothing was found. This call may first persist lazy expiry/drip housekeeping (see README) even if you only meant to read.

See what's in one layer — including `lapsed`, to answer 'what did I let go of'. Paginated: default limit 50, raise it only if you actually need more in one call (a large unpaginated layer can be megabytes of JSON, which will crowd out everything else in your context). `sourceGone: true` on an item means it's no longer found in any browser source that was successfully scanned (the record itself is never deleted). This call may first persist lazy expiry/drip housekeeping (see README) even if you only meant to read.

MUTATING TOOL. Move one or more `lapsed` items back to `pending`, resetting their 24-hour clock. Only works on items currently `lapsed` — for `kept`/`watching` items that need reverting, use `undo` instead. This call may first persist lazy expiry/drip housekeeping (see README) even if you only meant to read.

Counts per layer, how many decisions landed today (local calendar day on the machine running this server — see README), and how much is still sitting in `inbox` waiting for its daily drip slot. This call may first persist lazy expiry/drip housekeeping (see README) even if you only meant to read.

The 24-hour layer, oldest first — the actual to-do list. Each item includes `remainingMs` until it lapses on its own. `hasEverIntaken: false` means nothing has ever been scanned in (an empty pending list in that case means "you haven't started", not "you're caught up") — call `intake` first. This is where daily_triage starts. This call may first persist lazy expiry/drip housekeeping (see README) even if you only meant to read.

MUTATING TOOL. Revert an item to whatever it was immediately before one of ITS OWN history events — this works for `kept` and `watching`, not just `lapsed` (that's what `restore` is for). Only an item's current LATEST event can be undone; anything else comes back as `not-latest-event`, showing you the actual latest one to target instead. Select events either with explicit `eventIds` (from any tool's `history[].eventId`), or with `filter` (by source id / time range / attribution) to batch-undo every matching item's latest event at once. Pass `preview: true` to see exactly what would change first. Undoing never erases history — it appends a new entry, so the full trail including undos stays intact. This call may first persist lazy expiry/drip housekeeping (see README) even if you only meant to read.