context-intelligence-server-data-ops

# Context Intelligence Server Data Ops Step-by-step procedure for deleting Context Intelligence session data from a server, so the delete flows run the same way every time instead of being improvised fresh. **This is a direct, interactive conversation with the user** — every decision-critical step (preview, offer, impact, confirmation) is shown to them directly, in your own message, never summarized away by delegation. ## When to Use Load whenever the `server-data-ops` agent is about to run a delete flow: the current session, every session from the current working directory, a session found by description, or a session created by someone else. ## When NOT to Use - A plain `session_summary` preview with no delete on the table doesn't need this. - Reading or analysing session content is `graph-analyst`'s job (see `context-intelligence-graph-query`), not this skill. --- ## Tools - **`session_summary`** — read-only preview. Returns `{source: {name, url, origin}, summary: {...}}`. `summary` fields (the server's `DeletionPreview`): | Field | Meaning | |---|---| | `root_id` | The graph's root session id | | `session_ids` | Every session id in that graph (root + descendants) | | `node_count`, `edge_count`, `blob_count` | Totals for the whole graph | | `created_by` | Who created the root session | | `started_at`, `last_change` | ISO-8601 timestamps | | `subsession_count` | Sessions under the root | | `workspace`, `working_dir` | Where it ran | | `deletable` | `false` if anything in the graph is still receiving data | | `pending_sessions` | Session ids still receiving data, if any | - **`delete_session`** — the real, permanent delete. Returns `{source: {...}, result: {root_id, session_count, nodes_deleted, relationships_deleted, blobs_deleted, queue_sessions_cleaned}}`. - **`whoami`** — read-only identity lookup. Returns `{contributor_id, source: {name, url, origin}}` for the server you call it against. Used to compare against a session's `created_by` (see Ownership Check). All three accept `source` (name a server) and `list_sources: true` (discover the connectable set without acting). None takes a workspace — you always address a session by id. - **`todo`** — the standard todo-list tool. Used only in the folder cleanup, one item per candidate root session found, so a bulk cleanup never silently skips one. A lockdown hook denies this agent write_file, edit_file, apply_patch, and any direct graph-query tool — it guides the user through settings edits instead of making them, and delegates all search and narrative work to `graph-analyst`. --- ## Key Concepts **Current session id.** Comes from Amplifier's own runtime context — the `Session ID` field injected into your status context every turn. For any "this session" / "my current session" request, that value IS the session to act on. Don't ask the user for an id, and a typed id never replaces it — resolve from context regardless. Only ask directly if context genuinely has no `Session ID`. **Current working directory (for the folder cleanup).** Comes from the same runtime context — the `Working directory` field injected into your status context every turn, resolved the same way as the session id above. For any "this folder" / "this working directory" / "uploaded from here" request, that value is the directory to search — not a single session id. Don't ask unless context genuinely has none. **Current user identity (for ownership).** Never read from context and never guess. Call `whoami` for the *same server* the session in question is on, and use its `contributor_id` as the one reference identity for the comparison (see Ownership Check). **When the folder exclusion applies.** Offer it only when the data is both yours and from here — this session, this folder, this machine (the current-session delete, the folder cleanup). It's a local push-config setting on this machine, so it only stops future pushes from the current local context; it does nothing for data generated elsewhere. Don't offer it for a session found by topic/description (the find-by-description delete) or one that isn't yours (see Ownership Check). ## The "Session Details" Block Use this exact shape for any candidate or confirmed target (the find-by-description candidate list; the pre-delete confirmation in any flow): ``` Session <root_id> Created by: <created_by> Started: <started_at> Last updated: <last_change> Sub-sessions: <subsession_count> Working dir: <working_dir> Server: <source.name> (<source.url>) Still live: <"yes — cannot delete yet" if not deletable, else "no"> Summary: <your synthesized overview of the session, or "not available"> ``` Fill every field from a real `session_summary` call. Never fabricate a value you didn't receive. **Summary line.** Not returned by the server, and not built by this agent — it comes from `graph-analyst`, delegated to alongside the search (see the search step in "Find a Session by Description, Then Delete"). It returns a short synthesized overview of what the session was about, built from that session's **root**-session prompts only (never subsessions). This must be a synthesis, never a raw or verbatim prompt quote, and never a from-memory guess. If `graph-analyst` can't produce one, use "not available." --- ## Delete the Current Session Applies whenever the request refers to the user's own current session ("my current session," "this session," "the session I'm in") — even if the user also supplies a session id; a supplied id doesn't downgrade it out of this case or replace the runtime id. Route to **Clean Up Everything Pushed From This Working Directory** instead when the request is about the whole working directory, not just the current session ("this folder," "this working directory," "uploaded from here"). Route to **Find a Session by Description, Then Delete** when the request names or searches for some *other* session. 1. **Resolve.** Take the current session id from runtime context (see Key Concepts). Don't ask the user for an id. 2. **Prove.** Call `session_summary(session_id=<resolved>, list_sources=true)` and show the user: `root_id`, `created_by` (confirmed against `whoami` for the same server), `working_dir`, and `last_change` (flag if under a minute old — "may still be live"). Note every server the session exists on, from `list_sources`. If it 404s on every server, stop and tell the user plainly — never delete against an unresolved session. 3. **Offer the folder exclusion to the user directly, and wait for their answer**, before anything else proceeds. This is the destination **push filter** on the session's `working_dir`, not the delete scope — deletion always removes the whole session graph regardless of this setting. Show the setting `overrides.hook-context-intelligence.config.destinations.<name>.exclude` in `~/.amplifier/settings.yaml` — a list of gitignore-style patterns matched against a session's `working_dir`; adding one for the current folder stops that destination being selected. The agent has no filesystem tool, so it shows the setting in its own message and offers to guide the user through applying it — never edits the file itself. Make this offer every time, regardless of whether you can confirm the folder is currently included. Wait for their answer, confirm whether they applied it, then move on. **Two effects, both required — say so plainly in your message back to the user.** Writing the pattern into `settings.yaml` is the durable source of truth: it makes the exclude filter correct in a **new session** too, so a freshly started session in this folder honors it from the start. To also stop the **already-running** session (and any sub-session it spawns afterward) without a restart, the `set_ingestion_filters` tool is run in the **root session** — it re-reads `settings.yaml`, re-routes the live dispatchers, and reports `disk_consistent` so the live filter and the file are confirmed to agree. That tool lives in the root session (where the ingestion hook is mounted), not in this delegated agent — so if you cannot reach it, say so and ask the user (or the root session) to run it. Close the loop with a message of the shape: "Exclude saved to settings.yaml — **make sure the exclude filter is correct in a new session too** — and applied live to the current session; both the current session and any new session in this folder now stop pushing to `<destination>`." 4. **State the impact.** The whole graph — the session plus every descendant (forks, sub-sessions, delegated children) — plus its blobs and queue records, permanently, on the server(s) found in step 2. Shared nodes are kept; there is no undo. 5. **Confirm.** Explicit, restating the resolved id and the server(s) — a vague "yes" isn't enough. 6. **Delete, then verify, on every server** (see Multi-Server Handling). --- ## Find a Session by Description, Then Delete 1. Take the user's description (topic, content, date range, sometimes a server/workspace). 2. **Search + narrate.** For any non-trivial criteria (topic, content, date, workspace), delegate to `graph-analyst`. It runs the search AND returns, for each candidate, both the key facts and a short synthesized overview (see "Summary line" above) — you never query the graph or build the narrative yourself. This is a data-fetch delegation, not a hand-off of the conversation — the results come back to you and you keep driving the flow. Skip the delegation only for a trivial direct lookup — the user names an exact session id — and call `session_summary` on it directly. Cap the candidate set to a handful before per-candidate work. 3. Build a Session Details Block per candidate, using the overview `graph-analyst` returned (or "not available"), and present them; the user picks one. 4. Run the ownership check on the chosen session. 5. Re-run `session_summary` on the chosen id right before delete (a fresh preview, in case anything changed since step 2). 6. Confirm explicitly — id, counts, server(s) — then delete and verify on every server (see Multi-Server Handling). --- ## Clean Up Everything Pushed From This Working Directory (Yours, From Here) This is a find-by-criteria cleanup, not a current-session delete. The current-session delete's defining trait is the **current** session, resolved from runtime; this cleanup finds sessions by **criteria** — `working_dir` = this folder AND `created_by` = you — the same find-by-criteria shape as the find-by-description delete. The only thing it borrows from the current-session delete is the folder-exclusion offer, because it's your own folder being pushed. Applies when the user is worried that data from sessions run in THIS folder was pushed and should not have been — "I think I uploaded data from sessions in this folder, I want to delete it," "things from this working directory should never have been pushed." Route here instead of the current-session delete when the request is about the *folder*, not a single session; route here instead of the plain find-by-description delete when the criteria is specifically "this folder + mine" rather than a topic/date/server description. 1. **Apply the folder exclusion first**, before finding or deleting anything. Resolve the working directory from runtime context (see Key Concepts), the same way the current-session delete resolves the current session id. Offer the setting `overrides.hook-context-intelligence.config.destinations.<name>.exclude` in `~/.amplifier/settings.yaml` — the same folder-exclusion offer described in the current-session delete's step 3 — show it in your own message, guide the user through applying it (you never edit the file yourself), and confirm it's applied before moving on: while the folder is still in scope, continued ingestion would keep re-creating the very data you are about to delete. Apply it with BOTH effects from step 3 — persisted to `settings.yaml` (so the exclude filter is correct in a new session too) AND made live via `set_ingestion_filters` in the root session (so the current running session, and any sub-session it spawns afterward, stop immediately without a restart) — before you enumerate or delete. 2. **Run the S2 search, by criteria (this folder + mine).** Delegate to `graph-analyst` to enumerate every **root** session (never subsessions) whose `working_dir` matches the resolved directory AND `created_by` is you, checking every configured server (all-servers completeness applies to the search too, not only the deletes). It returns the candidate root sessions, their key facts, and a short synthesized overview for each — same as the find-by-description delete's search step. 3. **Propose the list.** For each candidate, build a Session Details Block using the overview `graph-analyst` returned (see "Summary line" above), present it, and add one item to a todo list (the `todo` tool) per session found — so every session is tracked and none is silently skipped. 4. **Delete all.** Walk the todo list one session at a time. For each: re-run `session_summary` (a fresh preview), run the ownership check (a session in this folder may not be the user's own), state the impact, confirm explicitly, delete, and verify on every server it is on (see Multi-Server Handling) — then mark that todo item done. Never mark an item done before its delete is verified. --- ## Ownership Check (Before Deleting Any Found or Named Session) Runs inside any of the delete flows above — the current-session delete, the find-by-description delete, or the folder cleanup — after the preview and before the delete confirmation. 1. From the preview, note the session's `created_by`. 2. Call `whoami` for the *same server* the session is on. Read its `contributor_id`. 3. Compare: - **Match** → the user's own session. No warning; continue normally. - **Differ** → tell the user directly, in your own visible message, that it was created by `<created_by>`, not them, and wait for a *separate*, explicit confirmation before deleting. - **`contributor_id` is null** (auth disabled or unresolvable) → say you can't confirm ownership and ask the user directly, waiting for their answer. Don't treat null as a mismatch. Never skip step 2 — warning from `created_by` alone, without resolving the acting user via `whoami` first, produces false "not created by you" warnings on the user's own sessions. --- ## Multi-Server Handling (All Flows) - `list_sources: true` on any tool returns the connectable set: every reachable server, with `name`, `url`, `origin` (`source` or `destination`). - `source=<name>` addresses one server. Omitting it uses the single configured tool source if there's exactly one, else the first destination; with two or more sources and none named, the tool refuses and lists valid names. - If a session exists on more than one server, name all of them and ask which to delete from (or "all"). - For **each** chosen server: delete, then verify that server's own result (or a fresh `session_summary`) before moving to the next — one delete succeeding says nothing about the others. - Report exactly what was removed and from where. If the session still exists on a server that wasn't chosen or checked, say so by name — never say "done" while that's true. ## Errors to Expect - **404** — the session id is unknown to that server. Say so; check for a typo or a different server. - **409** — still receiving data (not yet deletable), or an ambiguous id across workspaces. Never force or retry aggressively — tell the user it's still live. - **`ambiguous_source_selection` / `unknown_source`** — a source-selection problem, not a server error. Call with `list_sources: true` and ask the user to pick a name.