Meridian MCP Server

ALWAYS call get_sprint_items first to check for existing pending items before adding. Append a todo item to the project's sprint checklist. Use when starting work on a new version so the next session sees what's in flight. Optional: group items under a named objective with 'group'; attribute to a person with 'human_id'. Use 'depends_on' to block until another item finishes. Blocks near-duplicate titles (>=60% word overlap with an open pending/in_progress item) and returns the conflict; also warns (drift_warning) when the title looks already-shipped — 3+ keyword overlap with a migrations.py/_migrate_X or a recent commit; pass force=true to add anyway. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 2976e168 — attach a GENERIC POINTER to a sprint item: a portable, composable reference to a thing-in-a-source, grounded in LSP Location + W3C Web Annotation Selector composition. targets is an ARRAY of {uri, selector, subSelector?} objects (native multi-file, the LSP WorkspaceEdit pattern); the whole composite shape is stored as JSON, not per-domain columns. Every selector is an object with an explicit "type" PLUS that type's own field(s): • range — {"type":"range", "start_line":int, "end_line":int, "start_char"?:int, "end_char"?:int} (an LSP Range); the pointer IS the location. • symbol — {"type":"symbol", "qualified_name":"pkg.mod.func"} resolved against the cached code graph to a file+line. • node_id — {"type":"node_id", "id":"<element-id>"} of a doc_store element (an ingested-document structure node). NOTE: the field is "id", NOT "value". • zotero_key — {"type":"zotero_key", "key":"<zotero-key>"} of a Zotero library item. • text_quote — {"type":"text_quote", "exact":str, "prefix"?:str, "suffix"?:str, "archived_url"?:str, "archived_at"?:str, "canonical_url"?:str, "retrieval_hash"?:str} (W3C TextQuoteSelector; source_type "web" — a URL — OR a local .docx path, resolving via a docx paragraph-text match instead of an HTTP GET). Resolving re-fetches live and flags content drift (the cited passage silently changed/vanished). • finding_id — {"type":"finding_id", "id":"<finding-note-id>"} (source_type "experiment") addresses a save_finding artifact. • directory — {"type":"directory", "root":str, "include"?:[str,...], "exclude"?:[str,...], "manifest_id"?:str, "snapshot_id"?:str} (62640241) — a directory ROOT + glob include/exclude selector + optional snapshot/manifest identity. Resolving it (local paths only by default) walks the tree and returns a deterministic manifest + manifest_hash. • git — {"type":"git", "repository":str, "ref"?:str, "commit"?:str, "path"?:str} (62640241) — a Git repository identity; at least one of "ref"/"commit" is required. A line range within "path" is expressed via subSelector (a nested range), NOT a new field. Resolving it (local clones only by default) checks reachability against the repo's current HEAD via `git rev-parse`. • remote_fs — {"type":"remote_fs", "host_id":str, "filesystem_slot":str, "path":str, "lease_id"?:str, "session_id"?:str, "snapshot_id"?:str} (62640241) — an opaque tunnel-connector host + filesystem slot + remote path, optionally bound to the lease/session that captured it. No core-local default resolver exists (requires an injected, tunnel-backed resolver) — reported explicitly unresolved without one, never silently dropped. • artifact — {"type":"artifact", "manifest_uri":str, "fingerprint"?:str, "run_id"?:str, "item_id"?:str, "provenance_id"?:str} (62640241) — a build/output artifact's manifest URI plus an optional fingerprint and a link to the producing run/sprint-item/provenance record. Resolving it (local files only by default) hashes the manifest file to report its current fingerprint. An optional selector.subSelector nests finer granularity (W3C hasSubSelector) — e.g. {"type":"symbol", "qualified_name":"a.b.f", "subSelector": {"type":"range", "start_line":3, "end_line":4}} = 'these lines, within this function'. A subSelector is itself a FULL selector and MUST carry its OWN explicit "type" (it does not inherit the parent's). source_type names the domain (code | docs | citation | web | experiment | …). Each target may also carry target_kind: "existing" | "planned_new" (300a063d) — set "existing" ONLY when the file/symbol already exists (this is checked against the real filesystem and REJECTED if the path isn't there); set "planned_new" for a file this sprint item will CREATE, which is explicitly exempt from that check. Omitting target_kind keeps the pre-existing, unchecked behavior (defaults to "existing" in the stored shape but is never filesystem-verified) — set it explicitly to get real verification. 62640241 — a target may ALSO carry an optional freshness proof: {"content_hash"?:str, "source_revision"?:str, "resolver_version"?:str, "captured_at"?:str, "state"?: "current"|"stale"|"unknown"|"unavailable"|"ambiguous"}. Purely additive/opt-in; resolve_sprint_item_pointers recomputes a LIVE freshness_state for directory/git/remote_fs/artifact/text_quote targets by comparing this declared proof against what resolution finds right now. A target may ALSO carry an optional repo_root (W1-J) naming WHICH repo a relative uri is anchored to, for a companion-repo pointer whose uri lives in a different checkout than the one hosting this Meridian project (e.g. a paper repo alongside the code repo). Never send a raw absolute path here — pass the actual local path (or any stable label) you want the uri anchored to; it is converted to a portable, one-way identity fingerprint (basename + a content hash, never reversible back to the input) before being stored, the same scheme projects.repo_identity already uses for this project's OWN repo binding. Omitting repo_root means the pre-existing default: the uri is anchored to this same Meridian project's repo. A repo_root-bearing target's target_kind="existing" filesystem check is SKIPPED (never falsely run against the wrong repo's cwd) rather than checked or silently assumed verified. Malformed pointers are rejected with a clear error: a bad/missing selector.type, a missing required selector field (e.g. node_id without "id", git without ref or commit, a subSelector with no "type", an invalid target_kind or freshness.state, or target_kind="existing" at a path that doesn't exist). Returns the stored pointer. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Add an ephemeral note to the current session's scratch pad. Use for constraints, blockers, working assumptions valid only this session. Notes are auto-deleted when the session closes. Pass note_kind='thinking' for a thinking_sync (HOOKS_DEBUG_STATE) note: a structured snapshot of the reasoning state (what was tried, what failed, current confirmed state) that the dashboard renders with a distinct icon. Intended for Claude's client-side thinking_sync post-tool-call hook, which extracts the extended-thinking scratchpad and persists it here so debugging state survives across turns and into the next session brief. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 2976e168 — delete ONE generic pointer from a sprint item by its pointer id (the id returned by add_sprint_item_pointer / get_sprint_item_pointers). Idempotent: returns {pointer_id, deleted:false} when no pointer had that id, rather than erroring. To CHANGE a pointer's targets/source_type/label in place instead — preserving its id/created_at, and without the data-loss/visibility window a delete-then-re-add pair has — use relocate_sprint_item_pointer (W1-J); reserve this tool for when you actually want the pointer gone. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 2976e168 — list the GENERIC POINTERS attached to a sprint item (oldest first). Each pointer is {id, source_type, targets:[{uri, selector, subSelector?}], label, created_at} — the stored shape with its JSON targets deserialized. Read-only; does NOT resolve the targets (use resolve_sprint_item_pointers for that).

Read-only: List sprint items for a project. Optional status filter (todo|pending|in_progress|provisional_complete|done|failed|skipped|pushed|indeterminate). Cold sessions read this to know what's still owed. By default, items sharing a ``parent_id`` (subtasks) or ``item_group`` collapse into one summary row per cluster ({collapsed, cluster_kind, item_group_or_parent, count, done, description, ids}) instead of listing every item — pass expand=true for the full ungrouped list. Pagination (W1-A): pass limit and/or cursor to get a {items, has_more, next_cursor, total_count} envelope instead of the bare list — a project with hundreds of items (e.g. a large 'done' history) can otherwise return an unbounded, single-shot response. Paginated mode filters by status only — expand (clustering) is not applied to a partial page, since collapsing a cluster split across a page boundary would be misleading. Omit both limit and cursor for the legacy full list (unchanged, expand-aware) behavior.

[SUPPORT] Read-only: Get all ephemeral scratch-pad notes for the current session. Shown at the top of session briefs so every cold start sees active constraints. Pass note_kind='thinking' to fetch only thinking_sync scratchpad notes, or 'note' for only normal notes; omit for all.

[SUPPORT] Read-only: Return a SUMMARY of sprint items by status (pending/in_progress/done/failed) optionally filtered by version or item_group. Returns total, done, in_progress, pending, failed, percent_complete, and by_status (counts only — no per-item list; call get_sprint_items(status="pending") for the live item list). Useful to see how far through the sprint we are without listing all items. Pass session_id to also get a board_change field reporting items added since that session started (live-queue signal — call this between sprint items to pick up mid-run injections).

[MAINTENANCE] Update only the sprint — the short-term focus that changes each session or week. Any team member can call this; no ownership check. If pending items from the current sprint were never started, returns a WARNING block listing them. Pass force=true to override and overwrite anyway. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Edit fields on an existing sprint item: title, version, notes, human_id (assignee), group, deferred_until (enforced deferral), track, or depends_on (dependency ordering). Only the fields you pass are changed; omitted fields are left untouched. Pass an empty string for human_id, group, deferred_until, track, or depends_on to clear it. Returns the updated item, or an error if the id is unknown. For TWO OR MORE independent item patches, prefer the single execute_batch(operation='item_updates', entries=[...], mode='best_effort' or 'all_or_nothing', idempotency_key='...') call instead of repeating this tool: it validates and reports each item in input order, supports per-item correlation_key values, and makes retries idempotent. Use best_effort when one invalid item must not block the rest; use all_or_nothing when the whole patch set must succeed together. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Add a workspace-level wiki note that applies across ALL projects in this workspace (onboarding, cross-cutting conventions, shared infra). Unlike add_note, it is not tied to a project and is injected at the top of every project's context block + handoff. Comma-separated tags optional. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

Capture a workspace-level flash of insight into the 'drawer of inspiration' — cross-project ideas that don't belong to any one project yet. Unlike sprint items these are NOT executor-claimable; they require a human to review and promote them. Proposals start at status='raw' and progress through an enforced lifecycle: raw → investigating → promoted|rejected. Use advance_proposal_status to move through the lifecycle; use promote_proposal to convert one into a real sprint item. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Add an item to the workspace-level personal backlog — a cross-project board NOT tied to any single project (track thesis + Meridian + personal goals in one view). Use the per-project add_sprint_item for project work instead. 'group' is the cross-project bucket the item lives under (e.g. 'thesis', 'meridian', 'personal'); 'human_id' assigns it to a person. New items start as 'todo'. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: List workspace-level pinned decisions (active only by default, newest first).

[MAINTENANCE] Read-only: List workspace-level notes (newest first). Optional ?tag substring filter.

[SUPPORT] Read-only: List a bounded page of workspace proposals (human-authored flashes of insight), newest first. When status is omitted, defaults to 'live' proposals only (raw + investigating) — terminal proposals (promoted/rejected) are excluded so the default view reflects what's actually still open. Pass status='all' to fetch every status, or an explicit status (including promoted/rejected) to filter to just that one. Optional tag substring filter. Pass project_id (or project_name) to restrict the listing to that project's proposals only (a8afd8f9) — omitted, every proposal matching the other filters is returned regardless of scope. Pagination defaults to 20 rows (maximum 100); pass offset to fetch the next page. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: Read workspace-global default settings (applies across ALL projects in this workspace): hitl_auto_answer_default and sprint_name_default. Returns the singleton settings row.

[MAINTENANCE] Read-only: List workspace personal-backlog items (grouped by 'group', then position). Optional 'status' (todo/pending/in_progress/done/skipped/failed) and 'group' filters. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Update workspace-global default settings. Pass only the fields you want to change. hitl_auto_answer_default (bool) seeds new projects' HITL auto-answer behaviour; sprint_name_default (string) is the default sprint name; handoff_template (string) overrides the default full-mode handoff with a custom template — supports {{sprint}}, {{recent_tasks}}, {{decisions}}, {{north_star}}, {{version_goal}}, {{pending_items}}, {{notes}} placeholders. execution_mode_default ('autonomous'|'interactive', '' to clear) and code_intel_enabled_default (bool) are cascade defaults seeded onto NEW projects in this workspace (existing projects are unchanged). loop_enabled_default (bool) is the workspace default for /loop auto-continue that projects inherit when their loop_enabled is 'workspace'. tool_priority_map (object) sets a durable default MCP tool per semantic task category (e.g. {"code-reading": "Serena: find_symbol"}) — generalizes the per-item required_tool pin up one level; rendered as a HARD, unconditional directive in every /goal for matching pending items that have no item-level required_tool override. Pass {} to clear it. claim_verification_mode ('off'|'advisory'|'strict', '' to clear back to 'off') controls whether a PostToolUse hook re-checks claim_sprint_item/complete_sprint_item calls against live sprint-item state before trusting the calling session's own narration: 'off' = no check; 'advisory' = logs a warning on mismatch but never blocks; 'strict' = blocks the session on mismatch. Pass an empty string to revert a field to the server default. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Edit a workspace personal-backlog item: title, status, group, or human_id (assignee). Only the fields you pass are changed. Pass an empty string for group/human_id to clear it. Setting status to done/skipped/failed stamps completed_at. Returns the updated item. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 3f6b8715 — finalize a run as status='completed' (default) or status='abandoned'. outcome_summary and disposition (keep|discard|promote) are explicit and REQUIRED — rejected with {error} when missing/empty, even on a retry against an already-terminal run. result_receipt is bounded to 32KB; past that cap it is spilled to durable object storage (local content-addressed storage today, transparently upgrading to Tigris when configured) and replaced with a small pointer — never truncated, and rejected outright only if the spill itself fails. HARD INVARIANT: this call always writes an experiment_events row when the run newly reaches a terminal state here — status='abandoned' or an outcome_summary containing 'dead end'/'failed' (case-insensitive) auto-writes {event_type:'dead_end'}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Finalize an external job with an explicit terminal outcome. This never infers success from output files and never reopens a terminal record. It appends a final task-log event and refreshes the local snapshot. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] a5343387 — finalize a research run with a compact, byte-bounded receipt (16KB cap; exceeding it is REJECTED, never silently truncated). disposition is explicit and REQUIRED (keep|discard|promote) — never inferred from the run's outcome. Idempotent on an already-terminal run (completed/failed/abandoned/expired): a duplicate call returns the existing terminal state unchanged, never an error. Only disposition='promote' runs are eligible for promote_research_run, and only disposition in (keep, promote) runs are ever embedded into a handoff's research_run_receipts (see generate_handoff/build_continuation_manifest) — discard means exactly that. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

Mark a sprint item done. Pass task_id to link the task that shipped it. Pass session_id to get a board_change field (items injected mid-run) and an active-worktree merge reminder in the response. If the item is flagged required_notes, you MUST pass notes= (evidence: what shipped / how verified) or a task_id, or completion is refused (EVIDENCE_REQUIRED). If the item is flagged require_verification (e2e1b682), completion is refused (VERIFICATION_REQUIRED) unless an independent PASS is on file: pass verifier_session_id (a DIFFERENT session id from actor — a fresh, no-memory subsession that inspected the change with read-only tools) and verification_verdict='pass' to file and check the verdict in this same call. fdaa5b55 — if the item has a linked GitHub issue, the response carries a github_issue_action field: issues Meridian itself created (github_issue_source='meridian_auto') are commented on and auto-closed; any other issue (manual/legacy) only gets a proposed-closure comment plus a non-blocking HITL for human review — never auto-closed. 8693b6a8 — claim-ownership gate: if the item is claimed by a DIFFERENT actor than the one completing it, completion is refused (CLAIM_MISMATCH) UNLESS that claim is stale (claimed 2h+ ago, or the claiming session is dead/closed) — the exact stale-cleanup pattern of closing items left behind by a dead session keeps working automatically. For a live, non-stale foreign claim, pass force_foreign_claim=true to explicitly acknowledge and complete anyway. 5fe3502e — pass strict_evidence=true (or flag the item require_strict_evidence=true via update_sprint_item) for STRICT, fail-closed evidence verification: completion is refused (STRICT_EVIDENCE_BLOCKED, with typed evidence_errors codes — EVIDENCE_ABSENT/EVIDENCE_INVALID/EVIDENCE_STALE/WRONG_WORKTREE/UNCLAIMED_EDIT) unless evidence is present, verifiable, fresh, from the right worktree, and every modified file was claimed. Default (no strict_evidence, no require_strict_evidence) behavior is exactly the pre-existing advisory-only evidence checks — nothing changes unless you opt in. a8c0f3b7 — CODE-INTEL PROSPECTING RECEIPT gate: opt in at the PROJECT level via set_capability_manifest(capabilities=[{id:'code_intel_prospecting', ...}]) — no per-call flag needed, and a no-op for projects that never declared it. When declared, completion of an item that has touches_resources and no prospect_bypass is refused (CODE_INTEL_RECEIPT_MISSING) unless a durable receipt shows a real search_graph/find_symbol/prospect_symbol call happened since the item was claimed (see meridian.code_intel_receipt) — or refused (CODE_INTEL_UNAVAILABLE) when the capability is availability_policy='required' and code-intel itself is unavailable. Pass override_code_intel_receipt=true with a non-empty override_reason to acknowledge and complete anyway (audited). 'optional'/'degraded_ok' policies never block — they degrade with a code_intel_receipt_warning on the returned item instead. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] d2430713 — EXECUTOR GATE: call this AFTER you have actually run a wave's gate action list (push, deploy, wait, run_verification) to unblock the next wave's sprint items. You MUST pass the REAL structured result from run_verification as verification_payload — the server validates it (status=='ok', exit_code==0). A self-report ('I think it passed') or a fabricated payload is rejected with a clear error. On success, writes a wave_gate_results row and returns {gate_completed, wave_label, next_wave_label, next_wave_item_count, next_wave_item_ids, gate_id}. Each wave gate may only be completed once (duplicate calls return an error). Security note: this is a deploy-adjacent gate — only actual run_verification output satisfies it. ed8e4524 — SCOPED TO SPRINT VERSION: pass version (or session_id to auto-resolve the calling session's scope) so two different sprint versions that happen to share the SAME wave_label (e.g. both have a 'wave-2') never satisfy or unblock each other's gate — omit both to keep the exact prior project-wide behavior for a single-version project. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Mark a workspace personal-backlog item done (stamps completed_at). Returns the updated item. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 3f6b8715 — W1-M Experiment Registry: create a named experiment (a research question; many runs belong to one). Reuses the pre-existing experiments table (4376e655) additively — config_template/created_by (an unrelated ML-style tracking interface's own columns) are left untouched. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 3f6b8715 — read one project-scoped experiment by id.

[SUPPORT] 3f6b8715 — list an experiment's events, oldest first. Optionally scoped to one run_id. Includes BOTH auto-skeleton writes (dead_end/pivot/breakthrough) and manually recorded ones.

[SUPPORT] 3f6b8715 — read one project-scoped experiment run by id.

[SUPPORT] 3f6b8715 — list a project's experiment runs, newest-started first. Optionally scoped to one experiment_id and/or status.

[MAINTENANCE] 0ff8b982 — DURABLY link an already-indexed figure (doc_figures row) to its caption paragraph (a doc_elements id), by stable structural id rather than paragraph proximity. Use this to confirm an advisory suggested_caption_element_id returned by index_figure, or to backfill a durable link on a figure that was indexed before caption linkage was supported. Provide figure_id (the doc_figures.id of the figure to link) and caption_element_id (the doc_elements.id of the caption paragraph — a kind='figure' SEQ-field element from the section-tree store). This is the confirmation primitive for the 'Figure 3b used twice' ambiguity scenario: when index_figure surfaces suggested_caption_candidates (multiple captions in the same section), inspect them and call this tool with the correct one to confirm the durable link. Returns the updated figure row on success, or {error} when figure_id doesn't resolve to a known figure. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 8ca89e8f — DURABLY link a docx section/paragraph/figure/table (any doc_elements id — the same id space index_figure/index_table/link_figure_caption already anchor to) to the config-flag state that produced its underlying numbers. This is the check that catches 'results computed with the wrong flag state, then cited as current' — e.g. a flag that silently skipped a whole code path regardless of another flag, or a stale count cited after a fix superseded it. Typical flow: call get_flag_registry to find the flag's current file/line/default, compute the section, then call this tool with value=the value actually used and default=the default get_flag_registry reported (so get_flag_drift has something to compare the codebase's CURRENT default against later). Insert-only: re-linking the same (element_id, flag_name) pair after a re-verification adds a new history row rather than overwriting the old one. Returns {project_id, document_id, link}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 5dfe34b2 — attempt to link a manually-filed GitHub issue (one Meridian did NOT create) to a sprint item, extending fdaa5b55's automated comment/propose flow to it. No-ops safely (action='skipped') unless manual_issue_screening_enabled is on. When enabled: reads the issue's raw content, logs it (hashed, append-only) before any processing, runs a wave-relative velocity/anomaly check (non-blocking escalation only), then screens title/body/comments for hardcoded injection shapes — flagged content is never auto-linked (a human-review HITL is filed instead); only screening-clean content gets linked (github_issue_source='manual'). Linking NEVER by itself closes the issue — fdaa5b55's existing propose+HITL flow still applies at sprint-item completion time. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Record a typed lineage relation between two EXISTING proposals: from_proposal_id --relation_type--> to_proposal_id (to_proposal_id is the older/predecessor side). Idempotent — linking the same (from, to, relation_type) tuple again returns the same row rather than duplicating it. Rejected (ValueError -> {"error": ...}) if either proposal doesn't exist, if the two belong to different tenants/workspaces, or if the new edge would create a cycle in the lineage graph. Prefer create_proposal_successor when the successor doesn't exist yet — this tool is for linking two proposals that both already exist (e.g. marking one as a duplicate of another after the fact). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 42d398a5 — DURABLY link an already-indexed table (doc_tables row) to its caption paragraph (a doc_elements id), by stable structural id rather than paragraph proximity. The table analogue of link_figure_caption. Use this to confirm an advisory suggested_caption_element_id returned by index_table, or to backfill a durable link on a table that was indexed before caption linkage was supported. Provide table_id (the doc_tables.id of the table to link) and caption_element_id (the doc_elements.id of the caption paragraph — a kind='table' SEQ-field element from the section-tree store). This is the confirmation primitive for the ambiguous-multi-candidate scenario: when index_table surfaces multiple caption candidates in the same section, inspect them and call this tool with the correct one to confirm the durable link. Returns the updated table row on success, or {error} when table_id doesn't resolve to a known table. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

Capture an idea into a proposal — PROJECT-SCOPED BY DEFAULT (a8afd8f9). This is the preferred entry point going forward; add_workspace_proposal remains available as the explicit workspace-global opt-in for cross-project ideas. Pass project_id (or project_name) to scope the proposal to that project, XOR pass scope='workspace' to explicitly opt into a workspace-global proposal instead — an ambiguous call (neither, or both) is rejected with an error rather than guessed. Like add_workspace_proposal, these are NOT executor-claimable; a human reviews and promotes them via promote_proposal. Proposals start at status='raw' and progress through an enforced lifecycle: raw → investigating → promoted|rejected. A project-scoped proposal's project_id is enforced at promote_proposal time: promoting it into a DIFFERENT project is rejected unless allow_project_transfer=True (+ transfer_reason) is passed there. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Raise a typed, lane-blocking HITL gate for a materially ambiguous decision — legal/IP, product scope, destructive operations, production deployment, human acceptance of a contradiction, or other materially ambiguous decisions (category must be one of: legal_ip, product_scope, destructive_ops, production_deploy, contradiction_acceptance, other_ambiguous). Always starts state='blocked' (fail-safe) with no decision yet — routine read-only decomposition and bounded fallback work never needs a gate. affected is a non-empty list of sprint_item_id strings and/or generic pointer objects ({source_type, targets:[...]}) naming exactly what this gate blocks. Resolve with resolve_proposal_gate once a human decides. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Create a NEW, distinct proposal that is a version/successor of an existing one, linked to it by an explicit typed relation (supersedes/refines/forks/continues/duplicates/responds_to) — never by mutating the predecessor or overloading family_id/proposal_events (pinned decision 6aef812e). Inherits the predecessor's project scope (project-scoped stays project-scoped, workspace-global stays workspace-global) and family_id automatically. Idempotent: pass the same idempotency_key on a retry to get back the SAME successor rather than a second one — the underlying proposal creation AND the lineage edge are both independently idempotent. Returns {proposal, lineage, predecessor_id}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Read-only: list proposal HITL gates for a project, optionally filtered by category and/or (raw, stored) state. Pass sprint_item_id to instead list only the gates currently blocking/quarantining that one item (an effective-state-aware view — an expired auto_on_expiry gate is included even if its stored state says 'allowed').

[SUPPORT] Read-only: everything known about one proposal's place in its lineage graph in one call — raw relation edges touching it (either direction), its ancestor chain (walking predecessor-ward, nearest first), its direct successors (proposals that relate TO it, sequence-ordered), and its full descendant set (every proposal that transitively relates to it, breadth-first, nearest first). Descendants are capped at max_items edges with a non-silent 'descendants_truncated' marker reporting the true total when exceeded — ancestors/successors/links are not capped (a lineage chain/fan-out this large would itself be pathological). Returns {proposal_id, links, ancestors, successors, descendants, descendants_truncated}.

[MAINTENANCE] W1-K — record that derivative_path (e.g. a rendered PDF/DOCX export) was generated FROM source_path at a known content state. source_content_hash is the CALLER-computed content hash of the source document at generation time (the server never reads either file itself — hash it locally, e.g. sha256, before calling this). Always creates a NEW row with status='candidate' — re-rendering the same source/derivative pair over time is expected and never overwrites a prior registration; use promote_docx_candidate to make one candidate the accepted derivative for its source. generating_tool names the tool/script that produced it (e.g. 'pandoc 3.1' or 'export_pdf.py'); generated_at defaults to now (UTC) when omitted. Returns {derivative: {...}} including the new derivative_id. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Create or reaffirm a project-scoped record for long-running external work such as RunPod, SSH, Slurm, or CI. Meridian records the opaque external identity and resumable state, appends a task-log event, and writes an atomic host-local JSON snapshot. Do not include credentials or machine-local absolute paths in shared hints or metadata. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 3f6b8715 — register a project-RELATIVE artifact against a run. Rejects an absolute path (any shape capability_manifest recognizes, a bare leading '/', a drive letter, a UNC path, or a '..' traversal segment) or a secret-shaped value with {error}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Low-level: register this session without loading goal context. Use start_session instead for executor/human sessions — it registers AND returns goal + tasks in one call. Use register_session when you only need a session ID and will fetch context separately. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] cdd0ef6c — Create or reaffirm (upsert + heartbeat) this session's entry in the cross-client session recovery registry, so another client/session can tell whether it is resumable instead of guessing from a bare RC bridge id or transcript id. transport + optional local_identity (local_session_id, bridge_id, environment_id, argv — HOST-LOCAL ONLY) are used to compute a resume recipe and verified_resumable flag; local_identity itself is never written to the hosted registry, only to a host-local snapshot file. IMPORTANT: a remote_control transport with a bridge id but no environment_id is NOT assumed resumable (the RESCUE-D incident this registry exists to prevent) — verified_resumable will come back false with a reason. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 3f6b8715 — start a new active run (trial) under an experiment. Passing pivot_parent_run_id (which must belong to the SAME experiment) auto-writes a 'pivot' experiment_events row on the new run — unconditional, not a separate step. ttl_seconds is optional and unlike start_research_run has no forced default: omitting it means the run never auto-expires via expire_stale_runs. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 32d3d5de — Launch a long-running job on a remote host (e.g. a rented GPU pod) over a short-lived SSH connection used ONLY to start it, never held open: the command runs fully detached (nohup+setsid), so it survives the launching connection dropping for any reason. Returns quickly (a few hundred ms) with a job_id regardless of how long the underlying job takes — poll get_remote_task_status separately to check on it. Do not include credentials in command; use env vars already set on the remote host instead. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] a5343387 — start a bounded, ephemeral research/scratch run: an ADJACENT primitive for disposable subagent probes that should not need a formal sprint item, a formal claim_file, or a durable handoff entry unless explicitly promoted (see promote_research_run). mode='read_only' needs no claim_file at all. mode='isolated_write' requires is_isolated_worktree=true (never inferred — confirm the session is actually in an isolated git worktree, not the shared working tree) plus a non-empty allowed_paths list of project-RELATIVE paths bounding what may be written; any write outside that list is out of scope for the run. repository_id is a stable STRING identity for the repo/worktree (e.g. 'meridian-repo@worktree:wf_...'), never a machine-local absolute path. turn_budget bounds max turns/steps; ttl_seconds bounds wall-clock life (default 3600, 60-86400) — an expired active run is reaped by expire_stale_runs into status='expired'. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

Register a session and return orientation. Compact by default (session_id, sprint focus + status counts, 3 recent tasks, board_change count) to keep an executor's context small. Pass compact=false for the full block (goal XML, decisions, MERIDIAN.md instructions, workspace context, sprint items) — or fetch it later with get_session_brief. Pass version to scope the session to one sprint-version bucket (e.g. 'v0.1.x'): the orientation's sprint counts/items filter to it and the scope is remembered for the /goal template. Omit version to auto-scope to the bucket with the most pending items (empty board → unscoped). Also returns capability_contract (98aaccf4): a machine-readable {requested, effective, availability, manifest_hash, executable, executable_reasons, generated_at} object describing the project's declared capabilities and whether an executor can run right now — null if contract-building failed. Also returns execution_policy (75ac1c8e): a machine-readable {execution_mode, max_planning_turns, required_first_action, no_confirmation, permitted_parallel_wave, claim_before_edit, genuine_blocker_escalation} object — 'immediate' (default) names the exact first tool call to make and bounds planning turns before it; 'relaxed' is the explicit ask-first/planning posture. Derived from the project's execution_mode; max_planning_turns is executor_config-overridable via set_executor_config. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 2a654cb0 — DURABLE WAVE STATE: open a wave run before dispatching a parallel wave. Returns an immutable wave_run_id pinned to the canonical expanded board snapshot (revision_hash + monotonic revision_counter) the wave was planned against, so a session that dies mid-wave can be resumed against a manifest whose staleness is DETECTABLE instead of assumed. The snapshot is built server-side — you cannot supply one, because the point is to pin what the server saw. Pass item_ids (the sprint items in this wave) and optionally failure_modes ({item_id: 'stop'|'continue'}) to register them as children up front: a failed 'stop' child then structurally BLOCKS finalize_wave_run. degraded_tools ([{tool, reason, fallback}]) records which tools were unavailable while the wave ran, so a later reader knows the evidence quality. Returns {wave_run_id, run, children, revision_hash, revision_counter}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 273287cb — define a user-creatable Claude Code hook (PreToolUse | PostToolUse | Stop), generalizing past sprint_guard.sh/.ps1 (the only hook Meridian auto-writes today). Written into the repo's .claude/hooks/<slug>.sh / .ps1 on the next generate_handoff — the same auto-inject mechanism sprint_guard already uses. script_sh (POSIX shell body) is required; script_ps1 (PowerShell body) is optional — omit it to only ever write the .sh file. matcher is a Claude Code tool-name regex (e.g. "Edit|Write"), ignored for Stop hooks. blocking (default true) controls determinism vs. suggestion power: true writes the script byte-for-byte so its own exit code drives REAL Claude Code exit-code-blocking semantics (exit 2 blocks a PreToolUse call / a Stop / feeds PostToolUse output back to the model); false wraps it so an exit 2 is downgraded to 1 before it's written — the hook still runs and its output still surfaces, but it can never hard-block ('strong suggestion power' without determinism). name must not be 'sprint_guard' (reserved for Meridian's own hook) or collide with an existing hook's derived slug on this project — both raise a clear {error}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 273287cb — delete a user-defined hook by id (the id returned by add_custom_hook / get_custom_hooks). Idempotent: deleting an already-gone hook returns {deleted:false} rather than erroring, matching delete_sprint_item_pointer's convention. Does NOT remove any already-written .claude/hooks/<slug>.* files — those are simply no longer refreshed on the next generate_handoff. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 273287cb — list a project's user-defined hooks (newest first). Optional event filter and enabled_only flag. Each entry includes the derived slug (the filename stem used when written to .claude/hooks/) alongside the stored fields.

[MAINTENANCE] b4f4627f — the previously-missing generic enable/disable/edit path for a user-defined hook (id returned by add_custom_hook / get_custom_hooks): patches name, event, matcher, script_sh, script_ps1, blocking, and/or enabled without the delete+recreate round-trip add_custom_hook/delete_custom_hook would otherwise require. At least one editable field is required. Renaming re-derives the slug (same reserved-name / uniqueness checks as add_custom_hook); the db layer raises ValueError for a bad event, the reserved 'sprint_guard' name, or a slug collision — surfaced as {error}. Returns {error} (never raises) when hook_id doesn't resolve for this project. Flipping enabled true -> false also removes any already-written .claude/hooks/<slug>.* files immediately (best-effort, when the project has a resolvable repo_path) instead of waiting for the next generate_handoff to simply stop re-writing them — reported back as removed_files when any were deleted. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] R2-G — Read-only: status/diagnostics for the OPTIONAL AI-log -> OTel/self-hosted-Langfuse export adapter (meridian.ai_log_otel_export). Attempts NO network call — only reports whether the feature is globally enabled (MERIDIAN_AI_LOG_OTEL_ENABLED), the effective per-project enabled state, whether the optional opentelemetry client library is installed, the resolved endpoint/protocol/service_name, and the stored config/watermark row (last export status, last error, retry_count) if one exists. Meridian's own ai_log_events table stays authoritative regardless of this feature's state — see meridian.ai_log_otel_export's module docstring for the binding architectural decision (this is an export adapter, never a second source of truth). Returns {project_id, global_feature_enabled, effective_enabled, dependency_available, endpoint_configured, protocol, langfuse_compat, service_name, config}.

[SUPPORT] Log a task this session completed or is working on. Valid statuses: pending, in_progress, done, failed, backlog, future, backburner. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] d26b9943 (R2-B) — Read-only: EXACT-MATCH scoped search over ai_log_events, bounded and cursor-paginated. Every filter is a plain SQL equality (session_id/tenant_id/correlation_id/parent_event_id/actor_kind/actor_id/event_type) or an inclusive occurred_at range (since_occurred_at/until_occurred_at) — there is no lexical (FTS) or semantic index anywhere in this codebase yet, so the response's index_status field always honestly reports 'exact_only', never a fabricated 'complete'/'resolving' state. Filters are AND-ed together (more filters only ever narrow the result). Ordered newest-recorded-first (recorded_at DESC, id DESC — same contract as list_events), with a stable integer OFFSET cursor (pass a prior response's next_cursor back in — same contract as get_project_notes_page). Returns {project_id, filters, events, total_count, has_more, next_cursor, index_status}. limit defaults to 50, capped at 500.

[MAINTENANCE] R2-G — Set per-project override config for the OPTIONAL AI-log -> OTel/self-hosted-Langfuse export adapter. Every field is optional and left-as-is when omitted (partial upsert). 'enabled=false' force-disables export for THIS project even when the global MERIDIAN_AI_LOG_OTEL_ENABLED flag is on; 'enabled=true' or omitted defers to the global flag — a project can never turn export on when the operator has globally disabled it. 'otlp_endpoint' must be an http:// or https:// URL and is validated against this codebase's shared secret/path checks (meridian.secret_redaction.check_for_secrets + meridian.capability_manifest's embedded-credential/absolute-path patterns) — rejected with a ValueError if it looks like it carries a bearer token, embedded basic-auth credentials, or a machine-local path. An OTLP auth header/API key is NEVER accepted here — set the MERIDIAN_AI_LOG_OTEL_HEADERS environment variable on the server instead; there is no field on this tool or column in storage for it. 'langfuse_compat=true' is a purely informational hint (adds a resource attribute, shown in get_ai_log_export_status) for pointing otlp_endpoint at a self-hosted Langfuse OTLP-compatible ingestion endpoint — it does not change the wire protocol. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] W1-K — explicitly promote a status='candidate' docx derivative to be THE accepted derivative for its source_path, demoting whatever derivative previously held that role (if any) to status='superseded' in the same call — a real state transition with an audit trail (promoted_at/promoted_by_session_id on the newly-accepted row; superseded_at/superseded_by_derivative_id on the demoted one), mirroring promote_experiment_run's promotion-pattern precedent. Idempotent on an already-accepted derivative (mirrors promote_research_run's idempotency guard): a repeat call on the same derivative_id returns the existing accepted state unchanged (idempotent_retry=true), never a duplicate transition or an error. Rejects with {error} when the derivative's status is 'superseded' — a superseded derivative can never be re-promoted; register a fresh candidate instead. Returns {derivative_id, derivative, superseded_derivative_id, idempotent_retry}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 3f6b8715 — explicitly promote a run whose stored disposition is already 'promote' (set at completion time via complete_experiment_run) — rejects with {error} otherwise. Never triggered automatically by completion. Always auto-writes a 'breakthrough' experiment_events row. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

Promote a workspace proposal into a real sprint item, creating the link between them. The proposal must be in 'raw' or 'investigating' state. Creates a sprint item under the given project and sets the proposal's status to 'promoted' with promoted_to_sprint_item_id pointing to the new item. a8afd8f9 — when the proposal is project-scoped (created via add_proposal with a project_id) and this project_id differs from that, the promotion is rejected UNLESS allow_project_transfer=True is passed together with a non-empty transfer_reason (recorded on the resulting 'promoted' proposal_events row). A proposal with no project_id (created via add_workspace_proposal, or predating this column) has nothing to compare against, so this check never fires for it. Returns {proposal, sprint_item_id, sprint_item_title, project_id}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] a5343387 — explicitly promote a completed, disposition='promote' research run into a durable, addressable project finding (kind='finding' note, discoverable via get_findings/get_notes) summarizing its receipt. Never triggered automatically by completion — promotion is always a separate, explicit call. Rejects with {error} when the run's stored disposition is not 'promote'. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 6507e83a — Release a session's whole-document lease on a .docx file, if held. Returns {released: <0 or 1>, session_id, file_path}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] f7ee1ba7 — Release scoped docx-region claims held by a session. Without element_id releases all claims on the file; with element_id releases only that one element. Without file_path releases ALL region claims held by the session across all files. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Release a file lock (and any symbol claims this session holds on it). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] W1-I — voluntarily release a LIVE in_progress claim on a sprint item back to pending. Distinct from reconcile_stale_claims: that tool is for a claim whose owning session is dead/abandoned (multi-signal liveness classification); this is for a session that is still alive and has simply decided not to work the item after all (wrong scope, superseded, claimed by mistake) and wants to hand it back to the board cleanly instead of going silent and letting it eventually get swept as stale. Only the session recorded as the item's current actor may release its own claim — a mismatch is refused (NOT_CLAIM_OWNER) unless force=true is explicitly passed. Also clears the item's claimed_at/actor columns (not just status) and releases any file/symbol resource locks the claim held. Returns a structured {blocked: true, error: ...} dict (NOT_IN_PROGRESS / NOT_CLAIM_OWNER / RACE_LOST) rather than raising when it can't proceed; on success returns {item_id, prior_actor, prior_claimed_at, released_resources, item}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Create or update a workspace-scoped blog post (draft|published|archived lifecycle). Posts belong to the whole workspace, not a single project, and are served publicly at /blog/<slug> once status='published'. Pass 'id' to update an existing post; omit it to create a new draft. 'slug' is optional (auto-derived from the title, de-duplicated). Returns the saved post with a computed 'url'. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Phase-agnostic capture primitive: turn a finding into a durable, addressable note with provenance — works with ANY source (Claude's built-in web search, the arXiv MCP, Serena, a teammate). Decoupled from search so capture survives regardless of how you found it. The summary's first line becomes the note title; the note is tagged 'finding' + the source_type. Optionally links to a pinned decision. Returns the note. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 0bec79a7 (PROFILE-5) — Validate and persist ONE layer of the hosted_default -> workspace -> user -> project -> session profile contract (see meridian.profile_contract.FIELD_REGISTRY for the full field list and per-field allowed_layers/merge_strategy/narrow_only rules). REPLACES this scope's stored fields/reset_fields wholesale (not a merge) — to add one field to an existing layer, pass the full desired field set, not a delta. Rejects deterministically with {error} on an unknown field, a field not allowed at this scope_type, a secret-shaped value, a machine-local absolute path (outside the field's path_allowed_from_layer), an unsafe/destructive shell command (executor_config.test_cmd/deploy_cmd), or a malformed capability_manifest_ref. expected_revision enables optimistic concurrency: omit it for last-write-wins, or pass the revision you last read from get_profile_layer to fail with a structured {error, code: 'STALE_REVISION', current_revision} instead of silently clobbering a concurrent write. override_reason is accepted for forward symmetry with the narrow_only-widen override knob used at resolve time (get_effective_profile) but this tool itself never blocks a write on it — narrow_only/safe_direction enforcement happens at MERGE time, not write time, since a layer may legitimately declare any value for a field it owns. An idempotent no-op resave (identical fields/reset_fields) returns the current row unchanged with no revision bump. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] b924fd7c — save a recurring research query so it can be re-run and diffed over time via run_watchlist_query. Persisted as a project note (no separate table); the returned watchlist_id addresses it. Sources beyond paper_search's own 'arxiv'/'openalex' are reachable here by calling the underlying search function directly: 'semantic_scholar' and 'pubmed' (meridian.paper_search), 'github_code'/'github_repo' (meridian.github_search), and 'hn' (meridian.social_search). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: Return the raw MCP-tool-call heartbeat feed for the given executor session — a ring-buffer of the last tool calls (newest first, up to 50 entries). Populated automatically by the MCP dispatcher on every executor tool call, no log_task() needed. Use this to check whether an executor is still running when task_count is 0.

[SUPPORT] Read-only: Call this FIRST for project summaries or to see what a session did — returns session, tasks, decisions, and recent commits in one call. Replaces the start_session + get_context_block two-call pattern for worker/automation sessions. Returns sprint focus, pending sprint items, recent tasks, any blocking failures, and pending HITL requests in a compact XML envelope (<500 tokens).

[MAINTENANCE] Read-only: Return the full task log for the given session. Returns every log_task description logged during the session (transcript/task_count) PLUS a recent_activity ring-buffer of the last tool calls the executor made — even before log_task() was called. Use recent_activity to check signs of life in a running executor. Useful for post-session review, handoff, or remote planner polling.

[SUPPORT] cdd0ef6c — Read-only: fetch one session's recovery record (by session_id or recovery_id) plus, by default, a continuation payload that RE-DERIVES the live sprint board and this session's own still-active file claims — never a stored /goal body. resume_recipe is resolved from THIS machine's own host-local snapshot only and is null when this machine never registered that session's local identity.

[SUPPORT] 649e095f — Read-only: return a project's structured capability manifest (id/purpose/required_tools/fallback_chain/provenance/availability_policy/verification_command per capability), plus its schema version and a stable content hash for change detection. A project that has never set one gets an empty manifest back, never an error — old projects continue unaffected. Foundation-only: this is the raw declared manifest, not yet resolved against live tool/tunnel availability or profile inheritance. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 649e095f — Persist a project's structured capability manifest: a list of capability declarations, each with id, purpose, required_tools (non-empty list of tool/server names), optional fallback_chain, optional provenance (string or object), availability_policy ('required'|'optional'|'degraded_ok', default 'required'), and an optional verification_command. REPLACES the existing manifest wholesale (not a merge). Rejects deterministically with {error} on any unknown/missing field, duplicate capability id, secret-shaped value, or machine-local absolute path — manifests are shared, multi-machine project state, never a place for secrets or one executor's local filesystem layout. Normalizes to a stable, sorted-by-id order so the same capability set always hashes identically regardless of input order. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 02038afe — Persist ONE layer of the capability-inheritance chain: workspace -> user -> project -> sprint_version -> item (least to most specific). scope_type selects the layer; scope_id is that layer's key (a tenant/workspace id for 'workspace', a user/human id for 'user', the project_id for 'project', the sprint item's id for 'item', or the project_id for 'sprint_version' — the sprint version itself is resolved from whichever sprint item you query via get_effective_capability_profile). capabilities uses the exact same schema as set_capability_manifest and REPLACES this scope's capabilities wholesale (not a merge). disabled_capability_ids explicitly retracts capability ids this scope inherited from a less specific layer, without redeclaring them — that list also REPLACES whatever was previously disabled at this scope. provenance is an optional object recording non-secret context (e.g. config source label, a config/tool-list hash, observed_at, client/server identity, fallback policy) — never raw secrets or machine-local absolute paths, rejected the same way set_capability_manifest rejects them. Use clear_capability_profile to remove a scope's row entirely instead of replacing it with an empty one. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] f7ee1ba7 — Model B scoped-region claiming for .docx files. Claim a specific paragraph/element by its durable `element_id` (the w14:paraId surfaced by get_document_structure / update_paragraph) so another session cannot overwrite it concurrently. Two sessions can hold NON-OVERLAPPING element claims on the SAME file — the real precision benefit vs. a whole-file lock. An edit to a claimed element_id by another session is REJECTED structurally (not just advisory) at the update_paragraph level. A whole-file lock by another session blocks this claim. Returns {claimed: true, file_path, session_id, element_id} on success or {claimed: false, reason, message, conflicts} on conflict. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Claim edit rights on a file for this session. Whole-file by default (auto-expires after 2 hours). For symbol-level claims — so two sessions can edit the same file if they own different classes/functions — also pass `symbol` (e.g. 'AuthRouter' or 'AuthRouter.login') AND `content` (the file's full source). Meridian parses the source (stdlib ast for Python, tree-sitter for JS/TS/C/C++/Go/Rust/Java/C#), and hard-blocks if another live session already owns an overlapping line range — the block lists which symbols are still safe to claim. Unparseable content falls back to a whole-file lock. The response includes a `code_notes` list of code-anchored project notes (kind='code') for this file/symbol — read them before editing. Pass `item_id` (the sprint item you're claiming this file/symbol for) whenever you know it — it disambiguates the touches_resources amendment side-effect (c027922d) when your session holds more than one sprint item in_progress at once. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

Claim a pending sprint item: sets status to in_progress and records claimed_at + actor. Read-only: false. Rejects if the item is already in_progress, done, failed, skipped, its touches_files overlap active file claims from another live session, or (18c488b6) a touches_resources file:/symbol: entry is locked by another live session — this last check ACQUIRES the resource lock (via claim_file/claim_symbol) as part of claiming, is a hard block regardless of worktree isolation, and rolls back cleanly if the claim itself doesn't land. 54c488b6/54d2c2af: every symbol:/file: resource this acquires also gets a durable lock-granularity receipt (achieved symbol vs. coarse-fallback grain, and why), auditable after the fact independent of this call's response payload. 1b7eb437: on a project that has opted into the 'handoff_provenance_verification' capability (set_capability_manifest), the claimed item's response also carries handoff_provenance_warning (no matching verify_handoff_token/accept_handoff receipt attributable to this session_id was found) or handoff_provenance_receipt (a matching receipt) — informational only, never blocks the claim in this pass. Reuses this tool's existing session_id argument for attribution; no new argument is needed. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] c0168425 — Read-only: project-scoped, receipted export of ai_log_events (meridian.db.ai_log — the append-only ExecutionEvent log). Nothing captures events into this table automatically yet (see meridian.ai_log's module docstring); this exports whatever has been recorded via append_event so far. Filter with session_id/event_type/correlation_id/parent_event_id exactly like list_events. limit defaults to 5000 and is capped at 5000 — the response's truncated field is true when more matching rows exist than were returned. Returns {project_id, exported_at, filters, event_count, truncated, events, export_hash} — export_hash is a sha256 over the exported events so a caller can independently verify nothing was altered in transit.

[MAINTENANCE] c0168425 — Read-only: project-scoped, receipted export of stored ai_log artifacts (meridian.artifact_store — the local-first, content-addressed blob store an ExecutionEvent payload can point to via artifact_ref instead of inlining large content). Pass content_hashes to export an explicit subset (sha256:... values) — every requested hash must exist for this project, or the call errors rather than silently returning a shorter list; omit it to export every artifact currently stored for the project. Returns {project_id, exported_at, artifact_count, total_size, artifacts, export_hash} — each artifact entry includes its metadata plus base64-encoded content. export_hash covers the metadata only (not the base64 payloads) so it stays cheap to verify.

[MAINTENANCE] R2-G — Run ONE bounded export pass of new ai_log_events to the configured OTel/Langfuse-compatible OTLP endpoint for a project, resuming from the durable watermark left by the previous pass. Always safe to call: returns {"status": "disabled"} immediately if MERIDIAN_AI_LOG_OTEL_ENABLED (or this project's own override) is off, {"status": "unavailable"} if the optional opentelemetry client library isn't installed or no endpoint is configured, {"status": "idle"} if there is nothing new to export, {"status": "sent"} on full success, {"status": "degraded"} if part of the batch sent before a chunk exhausted its bounded retries (the watermark still advanced past every chunk that DID send — no silent gaps), or {"status": "sync_failed"}/{"status": "error"} if nothing sent this pass. NEVER raises, never blocks the caller longer than a bounded overall deadline, and never mutates or deletes any ai_log_events row — Meridian's own DB stays authoritative regardless of outcome. Returns {project_id, status, sent_count, batch_size, reason}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Read one project-scoped external job and its durable observation history. Use this from a fresh session before taking any action on a live job.

[SUPPORT] Read the project's live external-job register. By default terminal jobs are omitted so a new session sees only work that may require observation or resumption. The response also reports the host-local snapshot state.

[SUPPORT] Record a new observation for an existing external job. Use job_id or job_key, and pass only fields that changed; every write appends durable history and refreshes the local crash-surviving snapshot. Terminal jobs cannot be reopened or silently replaced. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 06df6ab3 — index ONE Word equation (OMML) against a document already stored in the doc-structure store — populated by ingest_document (which registers a docx/latex document's structure here in addition to storing the flat note text). Pass the SAME source/path you ingested under as `doc`. omml_or_latex is auto-detected: a string starting with '<' is treated as raw OMML XML (stored as-is); anything else is treated as LaTeX source (real OMML is generated best-effort — pure-Python latex2mathml piped through a hand-written MathML->OOXML mapper; returns null omml on an unsupported construct, never an error). Before inserting, the normalized LaTeX is fuzzy-matched against every equation already stored for this document — a near-duplicate is NOT silently dropped (the equation is still inserted) but IS surfaced via near_duplicates:[{equation_id, matched_id, matched_latex, score}] so you can spot accidental re-derivations. Returns {equation, near_duplicates}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] c623e648 — index ONE figure into the SEMANTIC figure index against a document already stored in the doc-structure store — populated by ingest_document (which registers a docx/latex document's structure here in addition to storing the flat note text). Pass the SAME source/path you ingested under as `doc`. This is the figure parallel of index_equation and is COMPLEMENTARY to the structural kind='figure' section-tree placement (it adds caption dedup + similarity, it does not replace placement). Provide file_path and/or caption. Before inserting, the normalized caption is fuzzy-matched against every figure already indexed for this document — a near-duplicate is NOT silently dropped (the figure is still inserted) but IS surfaced via near_duplicates:[{figure_id, matched_id, matched_caption, score}] so you can spot an accidental re-index. The referenced file_path is checked on disk: a missing file is FLAGGED (file_exists on the row + a missing_files entry), never a hard failure. Returns {figure, near_duplicates, missing_files}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 2622182d — index ONE table into the SEMANTIC table index against a document already stored in the doc-structure store — populated by ingest_document (which registers a docx/latex document's structure here in addition to storing the flat note text). Pass the SAME source/path you ingested under as `doc`. This is the table parallel of index_figure and is COMPLEMENTARY to the structural kind='table' section-tree placement (it adds caption dedup + similarity, it does not replace placement). Provide caption and/or table_index. Before inserting, the normalized caption is fuzzy-matched against every table already indexed for this document — a near-duplicate is NOT silently dropped (the table is still inserted) but IS surfaced via near_duplicates:[{table_id, matched_id, matched_caption, score}] so you can spot an accidental re-index. When paired_figure_id is omitted, the nearest figure in the same structural section is surfaced as suggested_figure_id (advisory, never auto-applied). Returns {table, near_duplicates}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Add a per-project wiki note (setup, gotcha, howto, env, ...). Free-form title/body; comma-separated tags optional. Optional kind (wiki=gotcha/rule/howto, insight=strategic/product analysis, reference=external/one-off docs, code=warning/context anchored to a file, document=ingested report/spec/thesis) controls how the dashboard renders it. For a code anchor pass kind='code' plus file_path (and optional symbol): the note is then surfaced automatically when a session calls claim_file/get_file_claims for that path, so the executor sees the warning before editing. Pass source (a URL or file path) to record where the note came from — set automatically by ingest_document. Tag a note 'roadmap' AND pass a committable category (TECHNICAL/ARCHITECTURAL/PRODUCT) to also append it to ROADMAP.md's roadmap-notes anchor. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Hard-delete a project note by id. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Read-only: Fetch one project note's full body by its per-project slug (the ``slug`` field from get_notes). The pull half of the list→read model — get_notes returns slugs without bodies, read_note pulls a single body when you need it.

[SUPPORT] 0bec79a7 (PROFILE-5) — Read-only: return the raw, single-layer profile for one (scope_type, scope_id) — one row of the hosted_default -> workspace -> user -> project -> session contract, with no merging against any other layer. A scope with no persisted row gets an empty profile back (revision=0, fields={}), never an error — mirrors get_capability_manifest's 'never a read error' contract. Use get_effective_profile instead when you want the MERGED, multi-layer view for a project.

[SUPPORT] 0bec79a7 (PROFILE-5) — Read-only: the hosted_default revision/audit history for one scope_id, newest first — the rollback/audit trail the profile contract requires for the one layer that is 'immutable once published'. Only hosted_default writes are ledgered; a non-hosted_default scope_id always returns []. Each entry carries revision, content_hash, lifecycle_state, fields, reset_fields, actor, and created_at.

[SUPPORT] 0bec79a7 (PROFILE-5) — Read-only: enumerate every persisted profile_layers row across the 5-layer hosted_default -> workspace -> user -> project -> session contract (see meridian.profile_contract / meridian.db.profile_layers for the full design), optionally narrowed to one scope_type. Each entry is shaped exactly like get_profile_layer's return value: scope_type, scope_id, schema_version, revision, fields, reset_fields, lifecycle_state (hosted_default only), content_hash, provenance, updated_at. Ordered by (scope_type, scope_id) for deterministic output — this is a raw listing, not a resolved/merged view; use get_effective_profile for the merged per-project result. An empty table returns [], never an error.

[MAINTENANCE] Create a new Meridian project. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: Find a project by name — look up, search, or resolve a project's project_id from its name (case-insensitive substring match). Use when the user names a project but you need its id. Returns the first hit with id, name, and sprint.

[MAINTENANCE] c39a1bd3 — set, change, or repair the executor posture on an EXISTING project (create_project only accepts execution_mode at creation time, and the workspace's execution_mode_default only cascades onto NEW projects — neither path can repair an already-created project's persisted mode). Confirmed live 2026-08-26: a child project can end up interactive/relaxed despite explicit autonomous instructions in its own project prose, with no prior MCP path to correct it (only the dashboard's PATCH /projects/{id}/settings route could). 'autonomous' (default) claims and runs sprint items immediately without asking; 'interactive' asks for direction first. Returns the updated project, or {error} if it does not exist. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] fefb596a — resolve this project's in-text citation markers to canonical Zotero items via Zotero's LOCAL API and materialise the cross-document 'cites' -> zotero_item edges (keyed on DOI). An OPT-IN, network-making pass — deliberately separate from ingest, which stays offline. For each kind='citation' marker without a zotero_item edge, the marker's ref is resolved: a DOI (doi:.. / a bare 10.x/y / a doi.org URL) matches the library item with that DOI; a zotero:<key> ref is a direct item lookup; a bare BibTeX citekey is a best-effort text search (fuzzy without Better BibTeX). When the resolved DOI matches a paper ALSO ingested in this project, the edge's target_document_id is linked too. IDEMPOTENT — re-runs only fill gaps, never duplicate. If Zotero is closed or its local API is disabled, markers simply stay unresolved (no error). Returns {resolved, unresolved, cross_doc_linked} counts. Requires Zotero running locally with the local API enabled (endpoint configurable via MERIDIAN_ZOTERO_API_URL). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Record a human decision on a proposal gate: the lane's new state (blocked | quarantined | allowed), the free-text decision, and the actor who decided (decided_at is auto-stamped). Refuses with {error} if the gate was already decided and has not yet expired — call reopen_proposal_gate first. An expired prior decision is treated as lapsed and a fresh decision is accepted directly. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 2976e168 — resolve EVERY generic pointer on a sprint item to its concrete location, dispatching by selector.type. A range target returns its location as-is; symbol resolves the qualified_name against the SAME live three-rung chain prospect_symbol uses (graph → Serena → semantic, 653579c5) when this session has an active code tunnel, falling back to the cached code-graph snapshot when it doesn't; node_id looks the element up in the doc-structure store; zotero_key resolves via Zotero's local API; text_quote re-fetches the URL (or docx paragraph text) and flags content drift; finding_id looks up a save_finding artifact note. 62640241 — directory walks the local root and returns a manifest + manifest_hash; git shells out to `git rev-parse` against a local clone to check ref/commit reachability against HEAD; artifact hashes a local manifest file for its current fingerprint; remote_fs has no core-local default (requires a tunnel-backed resolver — reported explicitly unresolved without one). Every one of these five ALSO gets a recomputed freshness_state (current/stale/unknown/unavailable/ambiguous) on its resolved target, comparing the target's declared freshness proof (if any) against what resolution finds right now. A subSelector narrows the outer resolution ('these lines, within this function'). Every dispatch is best-effort: an unresolvable target yields {resolved:false, reason} instead of an error, and the pass NEVER fails. Returns {pointers:[{id, source_type, label, targets:[<resolved-target>]}]}. Requires no network for range/symbol/node_id/directory/git(local)/artifact(local); zotero_key needs Zotero running locally and text_quote needs live web access (else those targets are just unresolved).

[MAINTENANCE] b241a437 -- Read-only: Return the positional/checkpoint index for the server_logs ring-buffer. The checkpoint is a lightweight 'table of contents' mapping minute-level timestamp buckets to the first/last row id and row count in that bucket. Use this for fast navigation through large log windows: find the bucket just before your target timestamp, then use its min_recorded_at as the since= argument to get_server_logs to skip all older rows without scanning. Complementary to search_server_logs (BM25 text search): this is positional navigation (WHERE in the log?) not semantic ranking (WHAT text?). The optional seek_to= argument returns the best since= hint directly. The index is rebuilt from the in-memory snapshot on every get_server_logs / search_server_logs call, so it is always current. Returns {total_rows, bucket_granularity_label, min_recorded_at, max_recorded_at, bucket_count, buckets:[{bucket, count, min_recorded_at, max_recorded_at, first_id, last_id}], seek_hint (when seek_to= given)}.

[MAINTENANCE] Read-only: Return recent application-level WARNING/ERROR/EXCEPTION log records (newest first, up to 500 entries). Captures any logging.warning() / logging.error() / unhandled-exception records emitted anywhere in the Meridian process — not just /mcp request metadata. Use this to diagnose server-side errors (OAuth flow failures, tools/list timeouts, deploy health issues, DB connection errors) without needing raw Fly.io log access. Complements get_connection_log (which covers per-request /mcp metadata only). Returns {count, since, level_filter, module_filter, entries}.

[MAINTENANCE] 222d54f8 — BM25 full-text search over the server_logs ring-buffer. Complements get_server_logs (which filters by level/module/since) with keyword-ranked retrieval — useful when you know WHAT went wrong but not exactly WHEN (e.g. search 'OAuth token refresh' or 'psycopg connection pool' across the last 2000 log records). Uses DuckDB native FTS (Okapi BM25) with Porter stemming over a concatenated body of level + logger + message + exc_text. Incremental: re-syncs only new/evicted rows on each call; repeat queries over an unchanged log window are near-free. Ring-buffer eviction is handled consistently — rows pruned from server_logs are removed from the FTS index on the next call. Returns {query, total_in_index, count, hits:[{id, level, logger, message, exc_text, recorded_at, score, bm25}]}. Empty/no-match query returns {hits:[]}.

[MAINTENANCE] 06df6ab3 — fuzzy-match a LaTeX string against every equation already indexed (via index_equation) for one stored document, best match first. Each result carries the stored equation row PLUS a difflib similarity score (0..1) against its latex_normalized. Useful before index_equation to check whether an equation is already present under a slightly different LaTeX spelling. Returns {document_id, matches:[...]} — an empty list (never an error) when the document has no stored equations, or doc doesn't resolve to a stored document.

[MAINTENANCE] c623e648 — fuzzy-match a free-text description OR a file path against every figure already indexed (index_figure) for one stored document, best match first. Each result carries the stored figure row PLUS a difflib similarity score (0..1) — the better of the match against its normalized_caption and against its file_path. Useful before index_figure to check whether a figure is already present under a slightly different caption or path. Returns {document_id, matches:[...]} — an empty list (never an error) when the document has no indexed figures, or doc doesn't resolve to a stored document. d2a3537a — pass outputs_dir to RESOLVE THROUGH to the outputs index: every matched figure with a file_path that names an already-indexed run output gains a linked_output field (the output's path, generating_script, canonical/archival flag, fingerprint), so 'does this plot already exist as a run output?' and 'where is it referenced in my thesis?' are one lookup (linked_output is null when the figure names no indexed output).

[MAINTENANCE] 2622182d — fuzzy-match a free-text description against every table already indexed (index_table) for one stored document, best match first. Each result carries the stored table row PLUS a difflib similarity score (0..1) against its normalized_caption. Useful before index_table to check whether a table is already present under a slightly different caption. Returns {document_id, matches:[...]} — an empty list (never an error) when the document has no indexed tables, or doc doesn't resolve to a stored document.

[MAINTENANCE] 9605edb0 — READ-ONLY cross-reference tracking: given a document and EITHER a doc_equations row id OR a symbol / normalized-LaTeX string, resolve it to ONE target normalized-LaTeX (an equation id uses that row's stored latex_normalized as-is; a raw string is normalized with the SAME normalize_latex that produced every stored latex_normalized) and return every place that target reappears in the document — matching equations (exact normalized-latex equality) AND paragraphs whose text textually contains the symbol. Each hit carries element_id, document_id, ordinal, matched_text, context (equation|paragraph) and an is_definition/is_reuse flag: the EARLIEST occurrence by ordinal is the definition, later ones are reuse — so a later mention can be checked to point back to the definition instead of assuming the reader remembers it. Hits are ordered by ordinal (definition first). Returns {document_id, target, resolved_from, hits:[...]} — an empty hits list (never an error) when nothing matches, or doc doesn't resolve to a stored document.

[MAINTENANCE] Read-only: list symbol-level claims on a file (who owns which class/function/method line ranges).

[MAINTENANCE] Read-only: symbols claimed by 3+ distinct sessions within 14 days — a refactor/ownership smell. Optionally scope to one file.

[SUPPORT] Delete a saved research watchlist query. Scoped to project_id + the watchlist tag, so it never deletes an unrelated note. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Read-only: list saved research watchlist queries for a project (optionally filtered by source_type), each with its watchlist_id, query, source_type, limit, and sort_by.

[SUPPORT] b924fd7c — re-run a saved watchlist query and diff its results against everything already captured for it. Every newly-seen result (matched by a per-source stable id — arxiv_id/openalex_id/s2_id/pmid/sha/repo/hn_id, falling back to url) is auto-captured via the same durable path as capture_research_finding/save_finding, tagged so the NEXT run recognizes it as already-seen. Returns {new_count, already_seen_count, new_results, captured, total_results}. Never raises — an unresolvable watchlist_id or a network/parse failure from the underlying search both degrade to {error}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] dffcde86 — Read-only: list active (not-removed) git worktrees registered for a project, newest first, each row including the owning session's name. Reads the same active_worktrees registry the merge guard (validate_worktree_merge) and the REST worktree endpoints (GET /projects/{id}/worktrees) use — this is the MCP-side view of it, for a session that wants to check what's checked out before creating a new worktree or investigating a stale one, without going through the REST API. Works identically on hosted and self-hosted Meridian: it only reads DB rows, never the filesystem.

[MAINTENANCE] Update the tunnel's active Serena repo at runtime. When a planning session switches to a different codebase, call this so subsequent Serena requests (find_symbol, find_referencing_symbols, etc.) route to the new repo without restarting the tunnel. Has no effect when no tunnel is connected. 32ba4125 — pass worktree_id instead of repo_path to activate a REGISTERED git worktree (one created via create_worktree / POST /projects/{id}/worktrees) as a validated code-intel context: the repo_path is resolved server-side from that worktree's own record, so an unregistered/arbitrary path can never be activated this way, and the response's `worktree` field carries fingerprint metadata (worktree_id, project_id, branch, path, registered_at). Passing repo_path directly is unchanged and still works for any path (main-repo/non-worktree use). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: Return the custom agent_instructions for a project. These are injected automatically by start_session so every session picks them up. Use this when you need to read or display the current instructions.

[MAINTENANCE] Set or update the custom agent_instructions for a project. Instructions are injected into every start_session response so AI sessions see them automatically — no need to repeat in every session. Pass null or empty string to clear. Use for persistent rules like coding conventions, deploy steps, or codebase notes. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 0fba4cb6 — MECHANICAL (zero-token) model-tier suggestion for a task or sprint item. Deterministic, rule/heuristic classifier: NO model call, NO DB, NO network — it mirrors how the ultracode orchestration script spends zero model tokens on routing. Pass a task descriptor (any of title, description, file_count, files, touches_resources, size) and it returns a suggested tier: {tier: 'haiku'|'sonnet'|'opus', score, signals:[{signal, detail, weight}...], rationale, mode:'mechanical'}. Cheap-leaning signals (title keywords like 'typo'/'docstring'/'lint', 1 file, size 'xs'/'s') pull toward 'haiku'; expensive-leaning signals ('refactor'/'migration'/'auth', many files, touched resources, size 'l'/'xl') pull toward 'opus'. Use it to route a task to the cheapest sufficient model before spawning an executor. FOLLOW-UP (out of scope this pass): a second LLM-backed 'semantic' mode that reads the full item for a nuanced second opinion.

[MAINTENANCE] PLANNING: Read-only synthesis of the current sprint into one structured brief — parallelizability (conflict-free groups + max fan-out), dependency chains (depends_on walked to the root), resource/file conflicts (items sharing touches_resources), and stalls (stall_count>0). Returns {summary, recommended_strategy, parallelism, dependency_chains, longest_chain, file_conflicts, stalls, blocked, running}. Call in planning sessions instead of stitching together get_parallelizable_groups + manual dependency/conflict analysis. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 133bfff6 — run a batch of TRANSACTIONAL mutation entries in ONE call, mixing entry kinds selected per-entry via 'kind': 'sprint_item_pointer' (attach a pointer — same shape as add_sprint_item_pointer: sprint_item_id, source_type, targets, optional label), 'sprint_item_update' (patch an EXISTING sprint item — same shape as update_sprint_item: item_id + at least one patchable field; sprint-item CREATION is not supported here, use execute_batch(operation='sprint_items', ...) or add_sprint_item for that), and (PROFILE-7) 'profile_layer' (upsert one scope_type+scope_id profile layer — same shape as set_profile_layer: scope_type, scope_id, optional fields/reset_fields/provenance/expected_revision; a stale expected_revision surfaces error_code='CONFLICT' with expected_revision/actual_revision in the outcome payload). Reuses the exact same validated apply/compensate logic execute_batch and the single-item tools already use — no separate/duplicated mutation path. mode is REQUIRED: 'all_or_nothing' validates every entry BEFORE mutating anything — any validation failure writes NOTHING (status 'rejected'); a mutation failure partway through rolls back every entry this call already wrote via a compensating delete/revert (status 'failed', per-entry status 'rolled_back'). 'best_effort' processes each entry independently (status 'ok' | 'partial' | 'failed'). idempotency_key is REQUIRED (pass null or "" to explicitly opt out) — a retried call with the identical (project_id, idempotency_key) tuple returns the FIRST call's stored result verbatim (idempotent_replay:true) instead of re-executing. PROJECT ISOLATION: an entry MAY carry its own 'project_id' field, but it MUST match this call's own project_id or the entry is rejected outright — a mutation entry can never target a different project. Returns {status, mode, project_id, idempotency_key, idempotent_replay, created_count, error_count, results:[{index, correlation_key, status, id, outcome, error_code, error_message, retryable}], request_id, committed_count, failures:[...failed results...], rollback_status: 'none'|'rolled_back'|'rejected'} — results is ALWAYS in input order. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 133bfff6 — run a batch of DOMAIN-AWARE, CONCURRENT read requests in ONE call. Each request names an 'adapter' + 'operation' + 'args'; independent requests (no depends_on) execute concurrently via asyncio.gather — this is pure in-process dispatch, no subagents/worktrees involved. A request with 'depends_on' (a list of other requests' 'request_id's in this SAME batch) waits only for its own declared prerequisites, not the whole batch; if a prerequisite fails, the dependent resolves immediately with error_code='DEPENDENCY_FAILED' and is never executed. Two requests with the identical adapter+operation+normalized-args+depends_on-set COALESCE to one execution — duplicates come back with cache_hit=true and coalesced_with=<the request_id that actually ran>; pass a non-default cache_policy to opt a specific request out of coalescing. Adapters currently registered: 'sprint_board' with operations 'get_sprint_items' (args: status, show_blocked, include_human, version, include_manual_blocker, include_deferred — same meaning as the get_sprint_items tool) and 'get_sprint_item_pointers' (args: sprint_item_id — 404s if that item belongs to a different project); and 'profile' (PROFILE-7) with operations 'get_profile_layer' (args: scope_type, scope_id), 'list_profile_layers' (args: optional scope_type filter), 'get_effective_profile' (args: optional session_id, user_scope_id, workspace_scope_id — returns the merged, generation-keyed effective profile across all 5 layers), and 'get_profile_layer_revisions' (args: scope_id, optional limit); and 'tunnel_research' (d17a437a, bounded cross-MCP research fan-out) with operations 'diagnostics' (args: optional refresh bool — reports which of the code/docs/outputs tunnel slots are connected right now and which specific tool names are routable on them; never fails on a missing tunnel context) and 'call' (args: tool, optional arguments object — dispatches ONE READ-ONLY tool call through whichever connected tunnel slot serves it; 'tool' must be on this adapter's own fixed read-only allowlist for the code-intel/meridian-docs/meridian-outputs MCP surfaces or it is rejected as VALIDATION_ERROR before any dispatch is attempted; NOT_FOUND when no tunnel is active or the tool isn't exposed on any connected slot — never dispatched blind). Returns {results: [{request_id, status, adapter, operation, result, error_code, error_message, elapsed_ms, cache_hit, coalesced_with}], elapsed_ms} — results is ALWAYS in input order. error_code is one of VALIDATION_ERROR, ADAPTER_NOT_FOUND, OPERATION_NOT_FOUND, DEPENDENCY_NOT_FOUND, DEPENDENCY_CYCLE, DEPENDENCY_FAILED, NOT_FOUND, TIMEOUT, INTERNAL_ERROR. This tool is READ-ONLY — for mutations use batch_mutate or execute_batch.

[MAINTENANCE] 6507e83a — Read-only: the live whole-document lease on a .docx file, if any (who holds it). Use before acquire_docx_document_lease or a bulk rewrite to see whether the document is already leased by someone else. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] f7ee1ba7 — Read-only: list active scoped docx-region claims on a file (who owns which element_ids). Use before update_paragraph to see whether the target element is claimed. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 02038afe — Read-only: resolve and return the MERGED capability profile for a project (optionally narrowed to one sprint item) across every applicable layer — workspace -> user -> project -> sprint_version -> item, least to most specific. A capability id declared at more than one layer resolves to the most specific layer's declaration; the response's capability_sources maps each effective capability id to the layer that won. overrides lists every capability id declared by more than one layer (each entry flagged conflict=true when the two declarations disagree on required_tools or availability_policy — the fields that change what an executor can actually rely on). disabled lists every disable that actually retracted an inherited capability. Pass sprint_item_id to also resolve that item's sprint_version and item layers; omit it to get just workspace/user/project. Never resolves against live tool/tunnel availability — this is the declared, merged profile only. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 0bec79a7 (PROFILE-5) — Read-only: resolve and return the MERGED profile for a project across every applicable layer — hosted_default -> workspace -> user -> project -> session, least to most specific (see meridian.db.profile_layers.get_effective_profile). The 'project' layer is synthetic: its 7 legacy ProjectSettings/executor_config fields come from the existing get_project_settings authority (zero duplication), and its 3 new fields (tool_priority_map, capability_manifest_ref, claim_verification_mode) come from the real profile_layers row. A hosted_default layer only applies when its lifecycle_state is 'active' or 'deprecated' — 'draft' and 'retired' never contribute fields but still mark the result degraded/not-executable via the returned executable/degraded/*_reasons fields. Pass session_id/user_scope_id to also fold in those layers; workspace_scope_id/hosted_default_scope_id default to 'singleton'/'global'. Returns {error} for an unknown project_id.

[MAINTENANCE] 8ca89e8f — read side of link_flag_to_section: for every recorded flag link (optionally scoped to one doc / element_id / flag_name — pass flag_name alone with no doc for the REVERSE query 'flag X changed, which sections does it touch'), re-scan the CURRENT codebase (same AST scan as get_flag_registry) and diff each link's recorded default against what the flag defaults to NOW. Only the most recently recorded link per (element, flag) pair is diffed — a re-verified section's older links are history, not live claims. Each result carries status: 'removed' (the flag, or this exact call site, no longer exists — the strongest staleness signal), 'drifted' (the flag still exists but its default changed since this section was computed — the section is possibly stale, needs re-verification), or 'ok' (no evidence of drift found). Returns {project_id, root_dir, links:[{...link fields, current_default, current_call_sites, status}], summary:{ok, drifted, removed}}. No recorded links returns an empty list, never an error — this is advisory, not a hard gate.

[SUPPORT] 45802b67 — scan a source tree for `os.environ.get(...)` / `os.getenv(...)` call sites (AST-based, not regex) and return a flat inventory of every config flag the codebase reads: {flag_name, file, line, default}. Only call sites where the flag name is a STRING LITERAL first argument are included — dynamic names (a variable, f-string, etc.) are skipped gracefully rather than erroring. The default is best-effort literal-eval'd from the second positional arg (or a `default=` keyword); a non-literal default evaluates to null. Useful for auditing config drift — 'what env flags exist, where are they read, what do they default to' — without grepping by hand. Returns {repo_root, flags:[...], count, unique_flag_names:[...], unique_count}. A missing/empty tree returns an empty flags list, never an error.

[SUPPORT] Read-only: Fine-grained — return just the goal fields (north_star, sprint, version_goal) in isolation. Use start_session or get_session_brief for full context including tasks and decisions. Use get_goal when you only need the raw goal fields.

[MAINTENANCE] Set or update the goal state. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Read-only: Poll a HITL request for the human's answer. Returns the row including status ('pending'|'answered'|'dismissed') and answer text.

[SUPPORT] Read-only: List HITL requests without needing UUIDs. OMIT project_id to list pending HITLs across ALL your projects (matches the dashboard) — planning sessions should call it this way so HITLs filed under another project aren't missed (a common cause of false 'no pending HITLs' confidence). Pass project_id to scope to one project. Returns pending queue plus answered/dismissed from the last 24 h by default so planning sessions can see what was recently decided without a separate call. Pass status='pending' for only the active queue, or status='answered'/'dismissed'/'all' for specific history.

[MAINTENANCE] PARALLEL COORDINATION (d3a3a01d): non-blocking barrier check across sibling sessions. Returns {all_done, pending, statuses}; a session is done when closed/archived/missing. The server can't block, so poll until all_done is true — the A2A 'wait for X, Y, Z to finish' primitive. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: Poll every 30 seconds until another session is closed or archived. Use this when you need to wait before editing a locked file. 6f9503a9 — BOUNDED: the wait times out after timeout_seconds (default 1800s / 30 min) and returns {done:false, timed_out:true, status} so a stuck subagent in a parallel fan-out fails that one item fast instead of hanging the whole batch. Pass timeout_seconds=0 or a large value to tune; there is no unbounded wait.

[SUPPORT] Turn a Word/PDF/text document into a queryable kind='document' note with a source link — a report, thesis chapter, or spec doc becomes searchable project memory. Pass file_path OR content (one is required): • file_path → Meridian extracts the text SERVER-SIDE, STDLIB ONLY: .txt/.md/.markdown and source files are read directly; .docx is unzipped and its paragraphs extracted (no python-docx). No new dependencies. • content → use this for .pdf and anything Meridian can't parse server-side: extract the text with YOUR OWN tools first, then pass it here. (Passing file_path for a .pdf returns an error telling you to do this.) title defaults to the file's basename; source defaults to file_path. The stored body is capped (truncated with a '…[truncated]' marker if very long; the kept prefix stays searchable). Meridian never summarizes — pass a summary as content if you want one stored instead of the raw text. Returns the created note (id, slug, title, source). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] db42acce — persist pre-parsed structural data (headings/figures/tables) into the doc-structure store, keyed on the SAME source as ingest_document(content=...) so find_similar_figure / index_figure / index_table / index_equation see the correct document_id. Use this when the .docx lives on the caller's local machine (not on the Meridian server): call the tunnel-side ingest_local_document_structure tool (from the meridian-docs extension) which parses the file locally and forwards the blocks JSON here. The source must exactly match the source that ingest_document stored the flat note under (default: the local file path). Returns {document_id, source, doc_type, element_count}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] d6bd60e0 — merge a phantom-duplicate project INTO another. Re-parents EVERY child row of the source project (sprint items, tasks, decisions, insights, notes, HITL requests, sessions, handoffs, pointers, …) to the target project via pure UPDATEs — NO row is ever deleted. By default the now-empty source project is soft-archived (status='archived', name prefixed with '[merged] '), never hard-deleted; pass archive_source=false to leave it untouched. Returns {source_project_id, target_project_id, moved: {table: count}, source_archived}. Returns {error} if source==target or either project does not exist. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Merge multiple sprint items into one. Source items are closed (skipped, merged_into=survivor). Returns the new survivor item. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 2ae25966 — READ-ONLY reverse provenance lookup over a run's OUTPUTS tree: the mirror image of resolve_figure_output's forward direction (figure -> source). Given a script or data file's source_path, scans the same local DuckDB outputs index search_outputs/annotate_outputs use for every indexed output whose recorded generating_script traces back to it — an exact (case/slash-insensitive) string match OR a basename match, so 'analysis/run.py' also matches an output recorded with generating_script='run.py'. This is the direction plain exact-path resolution can never answer, because that always starts from the output side: 'what did this script/data file produce?' — useful for auditing a stale Outputs_*_BACKUP folder mess by walking a source file's outputs forward, newest first, and comparing against what a document actually cites. Returns {outputs_dir, source_path, outputs:[{path, generating_script, is_archival, canonical_path, sha256, kind, size, mtime, csv_columns, json_keys}], total} sorted newest-first by mtime; total is the full match count before limit truncation. outputs is empty (not an error) when nothing in the tree cites this source, or when outputs_dir doesn't exist.

[SUPPORT] a0e9133e — READ-ONLY full-text search over a run's OUTPUTS tree (numeric/tabular/array artifacts), backed by DuckDB native FTS (Okapi BM25). Walks outputs_dir recursively and builds a persistent index: each .csv/.json contributes its extracted TEXT content plus a cheap fingerprint (CSV column names / JSON top-level keys / an inferred generating_script); each .npy contributes METADATA ONLY (never array content); images/other binaries contribute filesystem metadata + name only. The multi-word query is scored with BM25 and ranked hits are returned. Canonical-vs-archival is handled TWO-STAGE and is NEVER destructive: a filename heuristic (_old / _old_N / leading underscore) flags a CANDIDATE, and a SHA-256 content hash CONFIRMS — an archival copy byte-identical to its canonical twin is DEPRIORITIZED in ranking (is_archival=true, canonical_path set), while a same-name-pattern file whose content DIFFERS is surfaced as its own distinct hit (never collapsed). Nothing is ever deleted or hidden from disk. Pass include_archival=false to drop archival hits entirely. Returns {outputs_dir, query, total_indexed, hits:[{path, score, bm25, is_archival, canonical_path, kind, generating_script, csv_columns, json_keys, size, mtime, annotations:[{path, note, run_params, created_at, updated_at, source}]}]}. annotations is auto-included for each hit (any annotation keyed to the hit path OR a nearest ancestor directory) — no second tool call needed. A missing dir / empty tree returns an empty hits list, never an error. 3535b9ad — pass max_seconds to raise/lower the indexing budget (the "indexing slider"): a large or cold tree may not fully converge within the default budget on the first call — the result's partial=true field signals more indexing remains; call again to continue (each call resumes where the last left off, never restarts).

[SUPPORT] Create a pinned decision (editable constitution row). Use for the current authoritative truth that supersedes earlier statements. category is free-text; suggested values: STRATEGIC, COMPETITIVE, TECHNICAL, TACTICAL, BUSINESS, PRODUCT, ARCHITECTURAL. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Pin a workspace-level decision that applies across ALL projects (shared architecture, org-wide standards). Injected at the top of every project's context block + handoff. category is free-text (STRATEGIC, TECHNICAL, ARCHITECTURAL, PRODUCT, ...). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: Cross-reference pending sprint items against recent git commits and return items that may already be done. Uses keyword matching — confidence 'high' means 3+ keywords overlap (safe to mark done), 'medium' means 1-2 (verify first). Also surfaces 'notes_blocker_drift': pending items whose notes describe a deferral or blocker (keywords: FLAGGED, DEFERRED, BLOCKED, 'not implementable', etc.) but whose structured fields (blocker_kind, deferred_until) are both unset — these items will keep surfacing as ordinary claimable work until you call update_sprint_item with blocker_kind='manual' or deferred_until=<ISO timestamp>. Call during planning sessions to identify board drift before filing new items.

[MAINTENANCE] 56e9b3c7 — project/version-scoped, auditable stale-claim reconciliation sweep. The bulk counterpart to claim_sprint_item's own inline autonomous reconciliation (which only ever fires reactively, on a claim attempt against one already-claimed item) — use this for a scheduler path, or an explicit human/planner/executor-triggered audit across a whole board. Scans in_progress items in project_id (optionally narrowed to one version and/or an explicit item_ids allow-list — never cross-project), classifies each claim as active/stale/ambiguous via the same multi-signal check claim_sprint_item uses (session heartbeat liveness, claimed_at age vs. a 2h threshold, worktree/pid evidence — never age alone), and — ONLY when dry_run=False — resets every 'stale' verdict: atomically returns the item to pending, clears claimed_at/actor, releases the file/symbol resource locks the abandoned claim held, and writes an audit record. 'active' and 'ambiguous' verdicts are NEVER touched, dry-run or not — this never force-releases a genuinely live owner or treats an inconclusive signal as proof of abandonment. dry_run=True (the default) performs the full scan/classification and reports exactly what WOULD happen without writing anything — safe to run against any project, including live production boards, at any time. max_batch bounds how many in_progress candidates are scanned in one call (capped server-side); truncated=true on the result means more candidates exist than were scanned — page through with a follow-up call. Returns {project_id, version, dry_run, max_batch, candidates_total, scanned, truncated, active: [...], ambiguous: [...], stale: [...], reset: [...], errors: [...]} — active/ambiguous/stale hold classification verdicts, reset holds what was actually written back (only populated when dry_run=False), errors holds {item_id, error} for any one candidate whose classification or reset failed (never aborts the rest of the sweep). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 3f6b8715 — manually record an experiment_events row (dead_end|pivot|breakthrough|note|milestone). Separate from, and coexists freely alongside, the auto-skeleton events start_experiment_run/complete_experiment_run/promote_experiment_run/expire_stale_runs write unconditionally — this is the enrichment path for everything else worth recording. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 3af86d28 — record a corrective handoff when a blocked executor session reaches a wall after receiving a handoff (its evidence/scope no longer holds, a pointer stopped resolving, a required capability went away, etc.). Links to the immutable source_handoff_id (never mutated), classifies the blocker, and carries structured investigation evidence, added/removed/superseded pointers, and changed resources. Records status='draft' by default (or pass status explicitly). Pass idempotency_key to make retries safe — a repeat call with the same key returns the existing correction unchanged rather than duplicating it. Pass regenerate=true to ALSO, in this same call: re-resolve every added pointer live (repair), mark the source handoff invalidated/non-executable (its body is left untouched, for audit), and produce a new deterministic handoff revision (new body hash + provenance token) via the normal generate_handoff renderer. Idempotent: a correction that already produced a revision returns that same result again instead of regenerating a second time. A receiving executor should load the result via load_handoff (its 'correction' field) or a direct get_sprint — not by reconstructing the correction from log_task/note text. No DOCX or canonical project mutation is implied by recording a correction. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Single-call post-compaction recovery for planning chats. Returns a COMPACT snapshot — current sprint + progress, next pending items, the active session id, recent handoffs, high-priority (urgent) decisions, unvalidated assumptions, and key note slugs — small enough not to overflow context. Call this the moment a chat feels disoriented (e.g. right after a /compact) to re-orient in one round-trip. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: return the authoritative, compact manifest of ALL built-in Meridian MCP tools (name + one-line summary). Call this when you suspect your client's tool schema went stale ('I nuked the schema', a tool you expected is suddenly 'not found', or right after a /compact) — it is a plain tool CALL, so it works even on clients that ignore the notifications/tools/list_changed signal (e.g. Claude Desktop). Names returned here are canonical: a name present here but absent from your tool list is a stale-schema artifact, not a removed tool. If you're tunnel-connected, this also forces a synchronous re-aggregation of your tunnel's plugin tools (filesystem/code-intel/office/etc.) — the returned `tunnel` object carries a manifest_hash + slot_health + config_generation snapshot so you can tell a recovered/newly-configured slot is now visible without a reconnect.

[SUPPORT] 32d3d5de — Open a FRESH SSH connection (never the launching one) and determine a remote task's real status: completed (with the real exit code), still running (PID alive), terminated-unexpectedly (PID gone, no exit code — often OOM-kill or a host reset), connection-lost-but-possibly-still-running (the SSH connection itself could not be established, explicitly distinct from a failure), or unknown. Includes a bounded log tail and elapsed time. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 32d3d5de — Read the project's persisted remote-task register (last-known status only — no live SSH check is made; call get_remote_task_status for that). By default terminal jobs are omitted so a new/resumed session sees only work that may still need checking on.

Surface a question to the human-in-the-loop queue. ALWAYS use this to ask the human a question — never just ask in chat, which is invisible to the dashboard and to an unattended/autonomous run. IMPORTANT: when the project's HITL auto-answer mode is on (1=safe, 2=aggressive) and the question is not destructive / not require_human, this tool RESOLVES IMMEDIATELY and returns the chosen answer inline in the response (it does NOT block) — so calling it is cheap and is the right move even when you expect a quick yes/no. The active mode is reported in the start_session orientation as hitl_auto_answer_mode. urgency='blocking' means this session pauses until answered (poll get_hitl_request). urgency='normal'/'high' lands in the dashboard but doesn't block. assigned_to routes to a specific human_id (null = broadcast). kind='correction' files a non-blocking mid-run correction: never auto-answered, never blocks — an unattended executor picks it up at the next sprint-item boundary, applies it, and continues. Pass `options` (answer choices, rendered as buttons) and `recommended` (an option string or 0-based index) to flag the safe default — the dashboard highlights it and Enter submits it, and an auto-answer picks it. Set require_human=true for genuinely irreversible/destructive actions (token rotation, data migrations, rollbacks) so auto-answer can never approve it — only an explicit human reply unblocks it. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 5dfe34b2 — request enabling/disabling the OFF-by-default opt-in extension that lets the automated GitHub-issue comment/propose flow (never auto-close) also act on issues Meridian did not itself create, gated behind hardcoded content screening. enable=true ALWAYS files a require_human=true HITL (kind/require_human are hardcoded — this tool cannot be used to self-escalate; only a genuine human answering in the dashboard/API can enable it). enable=false disables immediately with no HITL (fail-safe direction) and is audit-logged either way. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] a5343387 — read one project-scoped research run by id.

[SUPPORT] a5343387 — list a project's research runs, newest-started first. By default terminal runs (completed/failed/abandoned/expired) are omitted so a fresh session sees only runs that may still be live.

[MAINTENANCE] Clear a tenant's stored command/config override for one plugin slot, resetting it back to the built-in default. Fixes the gap where stale_override detection (surfaced by list_plugins/get_plugin_details) could flag a stale per-tenant override but nothing could programmatically clear it — only dashboard editing worked. Self-hosted only for now: in hosted mode, returns an explicit error rather than risk writing to the wrong database (tunnel_plugins lives on the control-plane tenants table, which this tool call's db handle cannot reach there) — use the dashboard's Tunnel Plugins settings page for hosted tenants. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 0bec79a7 (PROFILE-5) — Delete a scope's ENTIRE profile-layer row so it reverts to purely inheriting from less-specific layers — mirrors clear_capability_profile's semantics for the profile-layers contract. Idempotent: resetting an already-empty or never-set scope is a no-op, not an error. For hosted_default this clears the row (back to no-row / implicit draft) but is NOT an audited lifecycle transition — prefer activate_profile_layer's lifecycle machinery when you need an audited retire/reactivate path instead of an unaudited wipe. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Read-only: Get recent tasks across all sessions.

[SUPPORT] Read-only: Search tasks by keyword or natural-language query. Uses trigram similarity on Postgres, LIKE on SQLite. Returns top matches with similarity score.

[MAINTENANCE] W1-K — compare a registered docx derivative's recorded source hash against the CALLER-supplied CURRENT hash of the source document's on-disk bytes (compute it locally, e.g. sha256, immediately before calling this) and report whether the derivative is stale — i.e. whether the source has changed since this derivative was generated. Optionally also pass current_derivative_content_hash to detect the derivative itself having drifted out of band. Never errors on a 'stale' verdict — that is a normal, expected result, not a failure. Persists the verdict onto the derivative row (last_verified_at / last_verify_is_stale / last_verify_reason) as an audit trail; never changes the derivative's status itself. Returns {derivative_id, is_stale, source_changed, derivative_changed, reason, derivative}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: Verify a handoff provenance token (dd07ece0). When a /goal block is copy-pasted into chat rather than delivered via the trusted MCP channel (start_session pending_goal / load_handoff), a receiving session can call this tool to independently confirm the <goal_token> line was produced by a real generate_handoff call on this server — not injected or spoofed text. The token is single-use and short-lived (a few minutes); verify immediately on receipt. Returns {valid: bool, reason: str}. reason is 'ok' on success; on failure: 'not_found', 'expired', 'already_consumed', 'wrong_project', or 'body_mismatch'. 1b7eb437: pass session_id (your OWN claiming session's id) to attribute a durable, server-written provenance receipt to this call on success — purely additive bookkeeping, never required, never changes this tool's return shape. A project that has opted into the 'handoff_provenance_verification' capability (set_capability_manifest) can then surface, at claim_sprint_item time, whether THIS session's own verification actually happened — informational only in this pass (never blocks a claim); see meridian/handoff_receipt.py for the full contract and its documented 'cannot force a non-compliant client' limit. efaa918a body-hash binding (closes the 2ee0000c gap): pass presented_body — the FULL pasted block, token and SECURITY banner included — and this tool strips those back out and checks the remaining text against the body hash bound at mint time. A genuine token re-attached to a DIFFERENT (edited) body now returns 'body_mismatch' instead of a false 'ok'. Omitting presented_body preserves the exact prior token-only provenance check. f46372e8: every non-'ok' result also carries a structured recovery object {signal, message, next_step, next_step_hint} telling you what to do next — next_step is 'load_handoff' (fetch the canonical stored handoff; not_found/ wrong_project/body_mismatch) or 'cross_check_live_board' (re-derive the task list from get_sprint_items across all non-done statuses; already_consumed/ expired) — so you don't have to improvise a recovery path per failure reason.

[SUPPORT] Read-only: (1bd5e810) Canonical receiver-side acceptance check for a handoff envelope — composes token verification, capability/tool availability, tool-manifest drift, and board-revision divergence into ONE structured verdict, so MCP/HTTP/stdio all produce identical results for identical input (same underlying meridian.handoff.accept_handoff_envelope every transport calls). Every input is optional and independently gated — supply whatever you have; an omitted check is skipped, never failed. Returns {accepted: bool, result: 'ok'|'STALE_HANDOFF'|'FOREIGN_PROJECT_CONFIG'|'BOARD_DIVERGENCE'|'TOOL_MANIFEST_DRIFT'|'BODY_HASH_MISMATCH'|'CAPABILITY_UNAVAILABLE', reasons: [str], token_check, identity_check, capability_check, tool_manifest_check, board_check, is_trusted_channel: false, delivery_source: str}. Checks run in this order, short-circuiting on first failure: (1) token — token/presented_body via the same verify_handoff_token check; a body_mismatch reason maps to BODY_HASH_MISMATCH, every other invalid reason (not_found/wrong_project/already_consumed/expired) maps to STALE_HANDOFF — the raw token_check.reason sub-field always preserves which one, since AGENTS.md treats not_found/wrong_project as real spoofing signals and already_consumed/expired as usually just a sibling session having already acted. (2) identity binding (22f2604d) — presented_body's own <project_start_config> tag vs THIS call's project_id/expected_repo_path, via meridian.handoff.check_project_start_config_identity; runs whenever step (1) did not already reject the envelope on its own basis — i.e. token verification passed or no token was presented — so a body whose embedded identity disagrees with project_id is FOREIGN_PROJECT_CONFIG even when the token itself verified ok. This catches a genuine token paired with a foreign project's start-config, which step (1)'s wrong_project check alone cannot (that only catches a token minted for a DIFFERENT project_id, not a body whose own tag disagrees with a token that legitimately matches project_id). It does NOT re-run after step (1) already failed (STALE_HANDOFF/BODY_HASH_MISMATCH) — that failure is independently sufficient to reject the envelope. (3) capability — required_tools vs available_tools: any required name missing from available_tools is CAPABILITY_UNAVAILABLE. (4) tool-manifest drift — expected_required_tools_hash vs a hash computed live from live_items' own tool_requirements fields (see meridian.handoff.compute_required_tools_hash): mismatch is TOOL_MANIFEST_DRIFT. (5) board revision — expected_board_revision (acf6f51a's manifest <handoff_manifest board_revision=...>) vs a hash computed live from live_items via meridian.handoff.compute_board_revision: mismatch is BOARD_DIVERGENCE. live_items is YOUR OWN get_sprint_items(...) result — this tool never queries the board itself, so you control exactly which project/version/status filter "live" means; pass the same filter used when the compared handoff/manifest was generated. is_trusted_channel is always false here (calling this tool at all means verifying something other than the trusted pending_goal/load_handoff channel — see those tools' own docs). Scope note: this is a validation/report tool, not a hard gate — it is not wired into claim_sprint_item in this pass. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 6507e83a — Whole-document cross-process lease for .docx files, the counterpart claim_docx_region never provided (that tool hard-requires a specific element_id). Use this when a session needs to rewrite an ENTIRE document (a bulk restructure, a canonical-merge promotion) and must block out every other writer, not just one element. Blocked by another live session's whole-file lock (claim_file) OR ANY other live session's claim on the file (lease or scoped element) — a whole-document lease requires the document be free of every other session's claims first. Once held, blocks every other session's writes (via check_docx_region_write_conflict, the same gate update_paragraph and the meridian-docs tunnel relay already enforce) and new claim_docx_region attempts on this file until released or expired (same TTL as every other claim in this module). Returns {leased: true, file_path, session_id} on success or {leased: false, reason, message, ...} on conflict — never raises. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 0bec79a7 (PROFILE-5) — Advance a hosted_default layer's lifecycle to 'active' — the single 'publish' operation for the hosted_default floor (fae6e882 pinned decision collapsed 'publish' and 'activate' into this one tool: a hosted_default layer becomes authoritative the moment it reaches 'active', so there is no separate publish step to expose). Only a draft -> active or deprecated -> active transition is valid; any other current state (e.g. retired, which is terminal) rejects with {error}. Idempotent: calling on an already-active scope is a no-op success (same revision, no new audit row). See reset_profile_layer for the non-audited 'clear the row entirely' path, or save_profile_layer followed by this tool for the audited draft-then-publish flow. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Transition a workspace proposal through its lifecycle. Enforced transitions: raw → investigating|rejected; investigating → promoted|rejected|raw; rejected → raw. 'promoted' is a terminal status reachable only via promote_proposal (which also creates the sprint item). Returns the updated proposal. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Read-only: Universal search across all project content: tasks, notes, pinned decisions, and sprint items. Uses LIKE matching (SQLite) or ILIKE (Postgres). Returns grouped results: {tasks, notes, decisions, sprint_items, total, cursor, limit, has_more, next_cursor}. limit (default 10, clamped 1..100) and cursor (default 0) bound and page each of the four lists with one shared offset (W1-A) — pass a prior response's next_cursor back in as cursor to fetch the next page; has_more is a per-list bool so you can tell exactly which list(s) still have more. sprint_items default-collapse any parent_id/item_group cluster (2+ items) into one summary row — pass expand=true for the full ungrouped list.

[SUPPORT] 9e02e448 — capture a human annotation for a path inside an outputs tree WITHOUT touching the filesystem. Upserts a row into the annotations layer of the local DuckDB outputs index for outputs_dir. Two tiers, same mechanism: Tier 1 = pass outputs_dir as path to annotate the whole tree ('what this experiment tree is about'); Tier 2 = pass any sub-path (file or directory) to annotate a specific run, file, or subdirectory ('PCA on, BFS off, overwritten 5x'). run_params is an optional free-form dict of parameters logged alongside the note (e.g. {"lr": 0.001, "batch_size": 32}). Annotations are automatically surfaced in search_outputs results — any hit's path (or its nearest ancestor directory) that has an annotation will have it included in the hit's 'annotations' field without a second tool call. A MERIDIAN_NOTES.md file placed anywhere in the tree is also auto-ingested into the same table on every rebuild, keyed to its containing directory. Returns the stored annotation as a dict. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Answer a pending HITL request programmatically. Marks it answered so the waiting session can resume. Use list_hitl_requests to find request IDs. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Archive a pinned decision by id. Soft-deletes to preserve the audit trail. Use when something was filed by mistake or is a duplicate. For retiring a valid but superseded decision, prefer update_decision(status=superseded). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 58a45b92 — PERSIST the parallel grouping: writes the conflict-free batches get_parallelizable_groups computes onto each eligible item's stored `wave` field (group i -> 'wave-{i+1}'), so parallelism becomes deterministic and inspectable (get_sprint_items surfaces `wave`) instead of recomputed every call. Only currently-eligible items (pending/todo, dependency-satisfied, unclaimed, non-manual-blocker) are labelled; blocked/in-flight/done items are left untouched (re-run once they clear). Idempotent — recomputes from the live board each call. Hand-override any item afterwards with update_sprint_item(wave=...). Returns {version, wave_count, assigned, waves: {'wave-1': [ids...], ...}, blocked_count, undeclared_count}. 605ca2c4 — if active executor sessions are detected, the response also includes active_session_warning: re-labeling wave numbers while a session is mid-flight can desync it from a /goal string that already references specific wave labels. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: List workspace-scoped blog posts, newest first. Optional 'status' filter (draft|published|archived). Each post includes a 'url' (/blog/<slug>).

[SUPPORT] Inline capture for web/paper research during planning: save a finding from a URL as an addressable note with the source link, optionally linked to a decision. A research-shaped wrapper over save_finding — arXiv URLs are tagged source_type=arxiv automatically, everything else as web. Turns web-search results into durable Meridian artifacts instead of evaporating. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Save progress mid-session. Runs auto_capture (buckets done tasks into a note), generates a delta handoff, and returns a compact summary with what was done, what's pending, and the suggested next /goal string (now the same canonical, token-embedded continuation block generate_handoff renders — verify it with verify_handoff_token exactly like any other /goal block). Call before context fills up or before ending a session. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] fefb596a — read the CITATION GRAPH of a project's ingested documents. Returns every in-text citation marker (a kind='citation' element parsed from an ingested .tex/.docx) together with its resolved edges: • bibentry edges — the intra-document link from a \cite{key} marker to a matching \bibitem/bibliography entry in the SAME document (materialised automatically on ingest). • zotero_item edges — the cross-document link from a marker to a canonical Zotero library item, keyed on DOI (materialised by the opt-in resolve_citations pass); target_document_id is set when the cited paper is itself ingested in this project. Each marker carries {element_id, document_id, ordinal, ref, text, edges:[{edge_kind, target_kind, target_ref, target_element_id, target_document_id, resolved_at}]}. Scope to one document with source (a stored source path/URL) or document_id; omit both for the whole project. Returns an empty markers list (never an error) when no document structure has been persisted yet.

[SUPPORT] 02038afe — Delete a scope's ENTIRE capability profile row (both its capabilities and its disabled_capability_ids) so it reverts to purely inheriting from less specific layers. Distinct from disabling individual capability ids via set_capability_profile's disabled_capability_ids — this clears the whole layer. Idempotent: clearing an already-empty or never-set scope is a no-op, not an error. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 0bec79a7 (PROFILE-5) — Copy one layer's fields/reset_fields/provenance onto another scope, going through the exact same validation/hashing path as save_profile_layer (not a raw copy) — the target scope's allowed_layers may differ from the source's, so a field the source layer legally carries can still be rejected at the target. Rejects with {error} when the source layer does not exist (revision=0 — cloning nothing is a caller error, not a silent no-op). Cloning INTO a hosted_default target never carries over the source's lifecycle_state — a fresh clone always lands in 'draft', exactly like any other first-ever write on a hosted_default scope; use activate_profile_layer afterward to publish it. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 93fce816 — Cursor-style LOCAL semantic code search over a source tree, entirely in a DuckDB sidecar (no cloud round-trip). Parses Python (stdlib ast) and TypeScript/JavaScript (tree-sitter) into SEMANTIC CHUNKS at function/class/method boundaries PLUS the un-named logical blocks that a named-symbols-only graph search can't reach (module-level dict/list literals, bare calls, __main__ guards, imports) — so a term that only appears in a bare top-level call is still findable. Incremental by a content MERKLE TREE: the root hash is compared first and only divergent subtrees are walked, so only the files that actually changed since the last pass are re-chunked (repeat calls on an unchanged tree are near-free). Search is HYBRID — DuckDB native FTS (Okapi BM25) for keyword match, fused via Reciprocal Rank Fusion with an OPTIONAL local-embedding vector leg (DuckDB VSS / HNSW cosine over a Model2Vec static model) when MERIDIAN_CODE_INDEX_VECTORS is enabled; with vectors off (the default) it is a complete pure-BM25 code search. Returns {root_dir, query, total_indexed, vectors_enabled, vectors_active, hits:[{chunk_id, path, language, kind, name, line_start, line_end, content, score, bm25, bm25_rank, vector_rank}]}. A missing dir / empty tree returns an empty hits list, never an error.

[SUPPORT] Commit a proposal's promotion through 'depth' (ce4883f3), cumulative over every shallower depth. Requires 'preview_hash' from a just-called preview_proposal_promotion with the SAME arguments — a mismatch (proposal or target project's board changed since) is rejected rather than silently committed against stale information, and nothing is written. Committing an already-satisfied depth is an idempotent no-op success (matches the preview's already_satisfied=true case). A genuine lost race against a concurrent caller (caught by the underlying race-safe functions) is reported honestly as a failure with a 'deviation_auto_resolved' audit trail — never silently retried or swallowed. When the promoted sprint item's resources or the proposal's own text match one of 3 narrow deviation heuristics (production_deployment / tenant_security_boundary / destructive_behavior), this files a durable HITL via request_hitl and returns hitl_pending=true WITHOUT completing remaining steps — pass a non-empty 'override_reason' to acknowledge and proceed anyway (audited). 'investigation_findings' and 'pointers' are recorded via append_proposal_update at the matching depth; 'pointers' entries are validated via meridian.pointers.validate_pointer (each needs source_type + a non-empty targets array of {uri, selector, target_kind?}). depth='executable_handoff' calls generate_handoff(selected_item_ids=[the new/reused sprint item id]) — scoped to exactly that item's dependency closure, with project/version/session identity. Returns {proposal_id, project_id, depth, already_satisfied, committed, deviation, hitl_pending, hitl_request_id}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Read-only: structural diff between two proposals — most commonly two adjacent versions in a lineage chain, but works for any two existing proposal ids. Reports per-field before/after/changed for title/body/tags/status/scope_type/project_id/family_id, plus a difflib similarity ratio and a unified diff for body specifically, plus whether the two are directly linked in the lineage graph ('adjacent') and the connecting edge(s) if so. Returns {from, to, direct_relations, adjacent, diff}.

[SUPPORT] 74a8f420 — PLANNING: configure (or on-the-fly reconfigure) a deterministic action pipeline attached to a wave or wave-range, ENFORCED STRUCTURALLY — not just advisory /goal prose. Once set, claim_sprint_item refuses (WAVE_GATE_PENDING) to claim any item whose wave sorts beyond wave_end until complete_wave_gate records real run_verification evidence for that boundary. actions is an ordered, non-empty list of {"type": ...} dicts — type must be one of push_dev | push_main | deploy | wait | run_verification (push_dev/push_main/deploy are run by the executor via trigger_workflow; run_verification maps onto the run_verification tool whose output complete_wave_gate requires as evidence; wait is a plain pause step; extra keys per action, e.g. {"type": "wait", "seconds": 30}, are preserved verbatim). wave_start (defaults to wave_end) documents a multi-wave range covered by one gate checkpoint. Re-configuring an un-passed wave_end is an upsert — the pipeline can be revised right up until an executor completes it; once passed the config is immutable (returns {"error": ...}). Returns {configured, gate_config_id, project_id, wave_start, wave_end, actions} on success. ed8e4524 — SCOPED TO SPRINT VERSION: pass version (or session_id to auto-resolve the calling session's scope) so two different sprint versions that happen to share the SAME wave_end label never reconfigure or immutably block each other's gate — omit both to keep the exact prior project-wide behavior for a single-version project. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: Return the recent /mcp connection-event log for this tenant (newest first, up to 200 entries). Every HTTP /mcp request Meridian receives is recorded: timestamp, MCP method (initialize/tools/list/tools/call/...), auth_result (success/oauth/no_token/invalid_token/expired), tools_returned (tool count for tools/list responses), client_user_agent, and HTTP response_status. Use this to diagnose client-side outages (zero tools returned, auth failures, unexpected User-Agents) in real time or after the fact without needing raw Fly.io log access.

[SUPPORT] Read-only: Return a compact project context block (north star, sprint, pending sprint items, recent tasks, recent decisions, active sessions) wrapped in a <meridian_context project_id="..." mode="..."> XML envelope for structured parsing by AI clients (v2.5+). The 'text' field in the response contains the XML-wrapped content. mode='full' (default) for Code Handoff into a fresh Claude Code session; mode='chat' for a shorter paste into a new claude.ai conversation. The HTTP route /projects/{id}/context-block returns the same content as unwrapped plain text.

[SUPPORT] Patch a pinned decision. Pass new_title + new_body to atomically supersede (creates a new active row, marks old as superseded with back-link). Otherwise patches body/title/category/status/priority in place. Editing the body appends the previous body to the append-only edit_log (read it back via get_pinned_decisions). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Dismiss a HITL request (won't-answer / no longer relevant). Stays in audit trail. Use list_hitl_requests to find request IDs. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 13462df2 — return the heading outline of a Word .docx WITHOUT ingesting it as a note. Meridian parses the .docx server-side (stdlib only, no python-docx, no persistent index) and returns paragraph_count, heading_count, and an ordered list of headings (level, text, para_id) — a fast structural map of a thesis chapter / spec before deciding what to read or ingest. Pass file_path to a server-accessible .docx. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 627187b8 — run a HOMOGENEOUS batch of management writes (all entries the SAME operation) with real atomic-or-independent semantics. Every entry in ``entries`` is validated and reported individually — no guessing whether a partial write happened. operation selects the entry shape: • sprint_items — create new sprint items. Each entry needs a non-empty 'title' plus any add_sprint_item kwarg (version, group, human_id, depends_on, priority, touches_resources, ...). Every entry's own 'action' (if present) must be 'create'. • item_updates — patch existing sprint items. Each entry needs a non-empty 'item_id' plus at least one patch_sprint_item field to change (title, status, notes, priority, ...). Every entry's own 'action' (if present) must be 'update'. • pointers — attach generic pointers (see add_sprint_item_pointer). Each entry needs 'sprint_item_id', 'source_type', 'targets' (+ optional 'label'). • notes — file sprint notes (see add_sprint_note). Each entry needs 'title' and 'body' (+ optional 'session_id' — falls back to this call's own top-level session_id when omitted — and 'note_kind'). Any entry MAY carry a 'correlation_key' (any non-empty string) echoed back on its result for reconciliation; every result also carries its 0-based input 'index' regardless. mode is REQUIRED and controls failure semantics: 'all_or_nothing' validates every entry BEFORE mutating anything — if any entry fails validation, NOTHING is written (status 'rejected'); if a mutation fails partway through, every entry this call already wrote is rolled back via a compensating delete/revert (status 'failed'). 'best_effort' processes each entry independently — one entry's failure never blocks the others (status 'ok' | 'partial' | 'failed' depending on how many succeeded). idempotency_key is REQUIRED (pass null or "" to explicitly opt out of idempotency protection for this call) — a retried call with the identical (project_id, operation, idempotency_key) tuple returns the FIRST call's stored result verbatim (idempotent_replay:true) instead of re-executing, making retries safe even for all_or_nothing batches that already wrote and rolled back once. Returns {status, mode, entry_kind, operation, project_id, idempotency_key, idempotent_replay, created_count, error_count, results:[{index, correlation_key, status, id, outcome, error_code, error_message, retryable}]} — results is ALWAYS in input order regardless of processing order. Each result status is 'ok' (mutated), 'error' (validation or mutation failure — see error_code/error_message/retryable), 'rolled_back' (succeeded, then undone by a later all_or_nothing failure), or 'not_attempted' (never reached because an earlier entry aborted the batch). max_entries caps this call (default 100); exceeding it is rejected before anything is attempted. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Store per-project executor defaults (repo_path, env_file, test_cmd, test_min, deploy_cmd, shell_type, branch). Merges onto the existing config — other keys (hostnames, filesystem_roots, …) are preserved. Pass repo_paths as an array of {cwd, hostname} known locations; they are merged into the existing repo_paths (deduped) rather than overwriting, so manual + hook-registered entries coexist. Executor sessions auto-load these when start_session(role='executor') is used. Credentials rule is always injected separately: read secrets from env_file only, never remote shell. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 3f6b8715 — list a project's experiments, newest first.

[SUPPORT] Bulk-insert sprint items from a single orchestrator call — decompose a goal into parallel work items without N sequential add_sprint_item calls. Pass a list of {title, description?, group?, version?} dicts; returns the list of new item_ids in insertion order. By DEFAULT (strict omitted/false) no duplicate guard is applied (the caller is assumed to have deduped) and titles that resolve to an empty string are silently skipped — unchanged, original behavior, kept for compatibility. 468ab67d — pass strict=true to opt into the SAME shared engine execute_batch uses (meridian.db.batch_management, add_sprint_item-backed): the 60%-word-overlap duplicate guard applies (per-item force:true still overrides it), idempotency_key makes a retried call with the same key replay the first call's result instead of re-inserting, and mode picks all_or_nothing (validate-then-insert with compensating rollback on failure, default) or best_effort (each item processed independently). In strict mode the response is the execute_batch response shape ({status, mode, entry_kind, project_id, idempotency_key, idempotent_replay, created_count, error_count, results:[{index, correlation_key, status, id, outcome, error_code, error_message, retryable}]}) PLUS the usual item_ids/count keys — a different, richer shape than the legacy bare item_ids/count, by design (a new opt-in contract, not a silent change to the old one). Each item may carry its own correlation_key (echoed back on its strict-mode result) and force (per-item duplicate-guard override, strict mode only). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Read-only: show active claims on a file — the whole-file lock (with the holder's session name, if any) plus any symbol-level claims. Use to check who owns a file before editing it. Pass project_id (and optional symbol) to also get a `code_notes` list of code-anchored notes (kind='code') for that path.

[SUPPORT] 2a654cb0 — IDEMPOTENT FINALIZATION: close a wave run opened by start_wave_run. Safe to retry: if the run is already merged this returns the ORIGINAL result with already_finalized=true, writes no row and appends no event (event_count is identical across the retry — that is the observable proof). Fails CLOSED in three cases: (1) a failure_mode='stop' child has failed — returns {finalized: false, blocked_by: [...]} naming the items; (2) expected_revision_hash does not match the board the run was planned against — you are holding a stale manifest, re-read the board first; (3) evidence is not a genuine run_verification result (status='ok', exit_code=0) — the SAME evidence contract complete_wave_gate enforces; a self-report is rejected. Returns {finalized, already_finalized, wave_run_id, status, finalized_at, finalizer_evidence, children_summary, event_count}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only (c35370cc): read stored session_findings for a project (newest first), optionally scoped by key and/or session_id. The read side of store_finding. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

EXECUTOR SESSIONS: MANDATORY - call at end of every session before disconnect. Never write markdown manually. Read-only: Generate a context handoff. mode='full' writes the complete L0/L1/L2 handoff; mode='delta' returns a compact session update (completed + pending + /goal); mode='starter' returns a <=20-line block for paste-after-/compact or cold start - project_id, start_session command, last 5 completed titles, top 3 pending IDs, /goal; mode='planner' returns strategic context for a claude.ai planning chat; mode='goal' (682005f4) returns ONLY the bare /goal block itself - no readiness header, no workspace decisions/notes, no L0/L1/L2 context - with each pending item's resolved code pointer(s), if any, rendered inline in <sprint_items>. FORWARD THE RETURNED content FIELD VERBATIM to the user (a5e8aa74) - the server delivers content as the EXACT raw handoff text, with NO Markdown code fence, header, or blockquote added around it (earlier versions wrapped it in a 4-backtick fence under 5234877f; that wrapping was removed because it broke copy-paste fidelity for the /goal trust protocol - see format_handoff_mcp_content in meridian/handoff.py). Output the field value as-is, as the sole plain-text bubble - do NOT add your own fence, header, blockquote, or any other wrapping on the calling side either. Do NOT just narrate that the handoff succeeded; paste the actual text. Also returns capability_contract (98aaccf4) on every mode: a machine-readable {requested, effective, availability, manifest_hash, executable, executable_reasons, generated_at} object describing the project's declared capabilities and whether an executor can run right now — null if contract-building failed. It also carries per-pending-item enrichment sections (item_tool_requirements, item_sprint_item_pointers, item_artifact_pointer_findings, item_executor_contracts, item_routing_summary) — each capped (537a7cef) to the first 15 items by id, with a sibling item_<section>_truncated {truncated, total_candidates, included} marker reporting the real count when a board exceeds that; the requested/effective capability lists are separately capped past 50 entries the same way. A capped section never drops data silently — the full detail for an omitted item is still reachable via a follow-up generate_handoff(mode='full') call. Every executor-facing /goal payload also includes an explicit <executor_item_ids> manifest containing every claimable item ID in deterministic order; receivers must use that manifest rather than parsing presentation prose or a truncated starter preview. Also returns scope (b8f89491) on every mode: {requested_version, effective_version, session_id} — which sprint-version bucket the handoff actually resolved to (explicit version arg wins over the session's own stored sprint_version; both null means genuinely unscoped, every version). Every mode's /goal text (full/delta/starter/goal, embedded in content or returned bare) also carries a structured <execution_policy execution_mode=... max_planning_turns=... required_first_action=... no_confirmation=... permitted_parallel_wave=... claim_before_edit=...> tag (75ac1c8e) right after <executor_directive> — the SAME canonical policy start_session's execution_policy field returns, so a receiver can identify the required first action from the tag attributes without interpreting prose. Also returns handoff_evidence_status (8a883f60) on every mode: an explicit {code_pointer_enrichment, resolved_pointer_annotation, freshness_requery, wave_gate_exclusion, graph_search_availability} object — each a {status: verified|skipped|failed|degraded, reason, fallback} entry for that best-effort step, so a silently-degraded handoff is never indistinguishable from a fully-verified one. Pass strict_evidence=true to fail CLOSED instead: if any capability comes back failed/degraded, nothing is rendered or persisted and the call returns {error: HANDOFF_EVIDENCE_BLOCKED, evidence_status, evidence_errors, message} — default (strict_evidence omitted/false) behavior is completely unchanged. Also returns continuation_status (ecc8b280) for full/delta modes: a {continuation_required, terminal_ready, execution_mode, actionable_count, actionable_pending_count, actionable_in_progress_count, actionable_item_ids, blocked_count, blocked_item_ids, reason} object reporting whether actionable pending/in_progress work remains on the live, version-scoped board with no recorded blocker_kind, while execution_mode=autonomous — the machine-readable signal that an autonomous session may NOT yet treat itself as finished. Pass checkpoint=true when THIS call is a mid-run progress report, not a final session-ending handoff — a checkpoint is never blocked by the gate below. Pass strict_continuation=true to fail CLOSED instead of just reporting: if continuation_required is true and checkpoint is not set, nothing is rendered or persisted and the call returns {error: HANDOFF_CONTINUATION_BLOCKED, continuation_status, message} — resolve/claim the remaining item(s), record a genuine blocker_kind on them, or call again with checkpoint=true. Default (strict_continuation omitted/false) behavior never blocks — continuation_status is still always returned so a caller can act on it voluntarily. Also supports selected_item_ids (cffb9323) — an explicit INCLUDE-ONLY item scope for safe parallel-follow-up handoffs. force_include_ids only ever WIDENS the pending list (re-adds specific deferred ids); selected_item_ids NARROWS it: when given, generate_handoff resolves a dependency-closed scope (the requested ids plus any transitively-required depends_on ancestor still todo/pending) and applies it identically across every executable mode (full/delta/starter/goal), so an isolated two-item follow-up handoff never emits the rest of the eligible version backlog or overlaps an active wave/batch a sibling session already owns. The rendered /goal carries a <selected_item_scope requested=... closure=... closure_hash=...> tag stating the exact selected ids and the wave plan — embedded in the body BEFORE the provenance token is minted, so the selection is bound into the SAME body-hash/token-integrity mechanism (efaa918a) as the rest of the /goal block. Fails CLOSED, not silently widened: a missing/foreign/wrong-version/already-in_progress/otherwise-non-pending requested id raises a structured refusal (error=HANDOFF_SELECTION_BLOCKED, selection_rejected) — nothing is rendered or persisted for that call. (7a373f41) A selection that validates cleanly but collapses to zero executable items once the manual/backburner/unprospected/wave-gate exclusion filters run instead refuses with error=HANDOFF_SCOPE_NON_EXECUTABLE, requested_ids, and an excluded_requested reason list — this same contract is identical across every connector surface (hosted HTTP MCP, stdio, and the REST /handoff route). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Search GitHub — a REAL external lookup (keyless), sibling to paper_search/social_search for external prior-art / competitive-repo research. Distinct from search_code, which only searches the CALLING project's own connected repo. Two keyless endpoints via the 'type' param: 'code' (default; GitHub Code Search — actual usage of a symbol/pattern/API across public repos) and 'repo' (GitHub Repository Search — competitor/prior-art repositories by topic/description/stars). Returns {query, count, results:[{title, authors, summary, published, url, ...}]} — code rows carry path/repo/sha/score, repo rows carry repo/stars/forks/language/score.

[MAINTENANCE] Read-only: compare the latest code-graph snapshots of two sessions — returns delta in node_count, hotspot_count, and file_churn. Use snapshot_graph_metrics first to record each session's current state.

[MAINTENANCE] 51a595e7 — write an OMML equation DIRECTLY into a stored document's source .docx (real OOXML write-back), collapsing the manual resolve->open->parse->splice->rewrite->reindex flow into one call. The document must already be stored in the doc-structure store via ingest_document (which registers a docx/latex document's structure here) AND have a filesystem `source` path to write back to. Locate the target paragraph by `para_id` — the paragraph's w14:paraId (or the synthesized 'p{index}' id that get_document_structure / find_similar_equation surface as element_id). equation_id_or_omml is resolved in order: the id of an equation already indexed for THIS document (its stored OMML is reused); else a string starting with '<' is raw OMML XML; else a LaTeX source (converted best-effort via latex2mathml -> MathML -> OOXML). position controls placement: 'append' (default) drops the <m:oMath> inline at the end of the paragraph; 'before'/'after' add it as its own display-equation paragraph adjacent to the target. After the write the document's equation index is resynced from the modified file (no separate re-verify step). Returns {document_id, source, para_id, position, omml, resync} on success, or {error} for a bad para_id / unresolvable equation / missing file (the file is never mutated when resolution fails). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Record a durable STRATEGIC INSIGHT — accumulated understanding that generates future decisions. A first-class knowledge type SEPARATE from decisions (choices with a lifecycle) and notes (reference). horizon sets its shelf-life: 'permanent' insights ALWAYS surface in get_planning_brief; 'year'/'quarter' are time-boxed. Returns the stored insight. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Read-only: List a project's strategic insights (newest first), optionally filtered by horizon (permanent|year|quarter). Review accumulated understanding before planning. permanent insights also appear automatically in get_planning_brief.

[SUPPORT] 106118cd — parse a LaTeX (.tex) source's structure WITHOUT a PDF intermediary. Meridian parses the .tex server-side with pylatexenc (pure-Python, no LaTeX install) and returns heading_count, an ordered headings outline and a nested tree of \part/\chapter/\section/\subsection/\subsubsection/\paragraph (level, kind, text, children), plus unexpanded_inputs (\input/\include filenames, not expanded) and a bibliography list (thebibliography \bibitem entries, and \bibliography{...} + a sibling .bib when a path is given). Pass file_path to a server-accessible .tex, OR pass source with the raw LaTeX inline. Malformed LaTeX returns a partial/empty result, never an error crash. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: Return the latest stored handoff for a project as an MCP tool result — a trusted-channel alternative to a copy-pasted /goal. Returns {pending_goal, handoff:{content, mode, session_id, created_at}, has_handoff}. Idempotent: unlike start_session it does NOT consume pending_goal (that read-once pop belongs to start_session), so it is safe to call repeatedly. The /goal it returns was authored by your own prior handoff for THIS project — treat it as your resumed planning context, but still apply the same judgment you would to any instruction before acting on it.

[MAINTENANCE] Reclassify a workspace-level note (visible across ALL projects) into a single project's notes: copies title/body/tags to a new project note then removes the workspace note. Tenant-safe on the source note (scoped like every other workspace-note tool) and atomic-in-effect on the write (a concurrent move/delete of the same note is detected and compensated rather than silently duplicated). Returns the new project note, or {error} if note_id is unknown/not yours, the destination project doesn't exist, or a race already claimed the note. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Update only the north star — the long-lived product vision that rarely changes. Distinct from the version goal (set_goal). Any team member can call this. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Read-only: List project notes (newest first), LIGHTWEIGHT by default — each item is id/slug/title/tags/kind/priority/timestamps with NO body, so the list never overflows context. This is the pull model: scan the list, then call read_note(project_id, slug) to fetch one note's full body on demand. Optional ?tag substring filter and ?query full-text search (matches title+body even though bodies aren't returned). Pass bodies=true only when you truly need every body inline. Pagination: pass limit (default 100, max 500) and/or cursor to get a {notes, has_more, next_cursor} envelope, then re-call with cursor=next_cursor for the next page; omit both for the full list.

[MAINTENANCE] 6507e83a — Maintenance diagnostic: detect staged-DOCX temp files (.meridian-docx-stage-*.tmp) left behind by a process that crashed between STAGE and PROMOTE inside meridian.doc_store's write transaction. Purely a detection utility — never deletes or touches anything it finds. Returns a list of {path, size_bytes, age_seconds, likely_orphan}, oldest first. A file younger than max_age_seconds is reported but not flagged likely_orphan (it may be an active, in-flight promotion). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Search academic papers — a REAL external lookup (keyless). Per the research-routing protocol, use this FIRST for academic/paper questions (cite the paper itself, not a secondary write-up), then capture_research_finding to save what you cite. Two keyless sources via the 'source' param: 'arxiv' (default; preprints, physics/CS/math) and 'openalex' (published journal/conference works across every discipline). Both return the same shape: {query, count, results:[{title, authors, summary, published, url, pdf_url, ...}]} — arxiv rows carry arxiv_id, openalex rows carry openalex_id + doi.

[MAINTENANCE] f978e588 — ID-addressable docx WRITE (the write counterpart of the get_element_by_id / paraId read primitive). Targets ONE paragraph in a stored .docx by its w14:paraId (the 'p{index}' fallback Word writes for an unlabelled paragraph) — NEVER by text match — rewrites its runs, saves the .docx in place, and re-syncs the doc_elements index row so it matches the new text. The document must already be stored in the doc-structure store via ingest_document (which registers a docx/latex document's structure here). Pass the SAME source/path you ingested under as `doc`. Provide EXACTLY ONE of: `new_text` (a plain string — one unformatted run) OR `runs` (a list of runs, each a bare string or {text, bold?, italic?, underline?} — basic run formatting is applied; the paragraph's original run formatting is replaced, not merged; its paragraph style/numbering is preserved). Returns {document_id, para_id, new_text, elements_resynced, source_path}. elements_resynced is 0 for a plain body paragraph (only headings are persisted as elements) — that is expected, not a failure. Errors (never a silent no-op) when the doc/source/para_id doesn't resolve. f7ee1ba7 — pass session_id to enable scoped-region claim enforcement: if another session has claimed the target para_id (or holds a whole-file lock), the write is REJECTED with error='docx_region_conflict'. Use claim_docx_region to acquire your region before writing. 5988a5bb — mandatory post-write verification now re-reads the file from disk and confirms the target paragraph's text actually landed before this ever reports success; on a rare verification failure the write is best-effort restored from backup and an error is returned instead. Response also now includes pre_counts/post_counts (the media/style/equation/relationship structural manifest from before and after the write). Three further OPT-IN parameters (each omitted by default, byte-identical behavior when omitted): expected_content_hash — a fail-closed precondition: if the source file's current on-disk content hash doesn't match, the write is REJECTED before anything is touched (get the current hash from a prior get_document_structure/get_structure staleness check). draft_output_path + wave_run_id (both-or-neither, with session_id also required) — writes to an ISOLATED draft path instead of the canonical file, claiming the paragraph as this wave's anchor via the real docx-merge manifest so a conflicting concurrent draft on the same paragraph is rejected; response carries draft_path/wave_run_id/ is_draft instead of elements_resynced (the canonical index is not touched until a merge). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: Return clusters of pending sprint items that are safe to run simultaneously. Filters pending/todo items (optionally by version) whose depends_on is satisfied, then greedily partitions them into groups where no two items in a group share a touches_resources identifier. The orchestrator fans out each group as a parallel subagent batch and runs the groups in sequence. Returns {version, groups: [[item,...],...], group_count, eligible_count, undeclared_count, blocked: [...]}. Items still waiting on an unfinished dependency are listed under 'blocked', not in any group. Makes parallel sprints system-enforced rather than LLM-guessed. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 7acb8563 — set, change, or clear a project's parent AFTER creation (create_project only accepted parent_project_id at creation time). Use this to retroactively nest a project under another, or to detach it. Enforces the one-level-deep invariant (3b6ff466): the parent must exist and be top-level, a project can't be its own parent, and a project that already has subprojects can't become one. Omit parent (or pass empty) to DETACH — make it top-level. Returns the updated project; {error} on an invariant violation. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Read-only: List pinned decisions, highest priority first (urgent → normal → low, then newest-first). Active only by default. Each row includes its priority and a parsed edit_log array of prior bodies ({body, ts}) recorded on every in-place body edit. Pass query to filter to decisions whose title or body matches (every whitespace-separated term must appear in the title or the body, same multiword-AND convention as search_tasks/search_all) — omit or pass a blank string for no filter (W1-A).

PLANNING SESSIONS: CALL THIS FIRST before anything else. Read-only: Return a compact planning context — sprint, north star, pending items, in-progress items, recent tasks, active sessions, recent decisions, unvalidated assumptions, the last session's output (last_session), and a new-handoff signal. No session registration needed. Designed for planning chat sessions that need to see project state without side effects. Pass `since` (a prior call's generated_at) to flag only handoffs filed since you last checked. pending_items/in_progress default-collapse any parent_id/item_group cluster (2+ items) into one summary row — pass expand=true for the full ungrouped list.

[MAINTENANCE] Read-only: Full schema for one named plugin (all tool definitions, description overrides, and stored skill guide if available). Use list_plugins first to see which plugins are active, then call get_plugin_details(name) to load the schema for a specific plugin on demand.

[MAINTENANCE] Read-only: Lightweight index of active tunnel plugins — name, description, enabled state, and tool_count. Does NOT return full tool schemas (use get_plugin_details for that). Dramatically reduces context bloat vs. dumping all plugin schemas at startup (~500 tokens vs 50k+). Returns an 'active_plugins' list plus any stored skill notes.

[SUPPORT] Read-only (ce4883f3): preview what commit_proposal_promotion would do for a proposal at a given depth, WITHOUT writing anything. Depths are cumulative, shallow to deep: 'proposal' (intake/scope only) -> 'investigation' (+ raw->investigating transition) -> 'pointers' (+ pointer recording) -> 'sprint_items' (+ promote_workspace_proposal) -> 'executable_handoff' (+ a handoff scoped to the new sprint item). Returns {proposal_id, project_id, depth, already_satisfied, contract_status, would_create, wave_preview, preview_hash, computed_at}. 'already_satisfied'=true when the proposal's current status already reaches this depth (e.g. already 'promoted' and depth='sprint_items') — no-op, nothing further to preview. Otherwise 'contract_status' reports each of the 8 proposal-to-execution contract parts as present/would_create/optional_at_commit/not_applicable; 'would_create' shows the synthetic sprint-item preview (title/version/touches_resources) once depth>='sprint_items'; 'wave_preview' shows which existing parallel-safe group the item would join or conflict with (via get_parallelizable_groups, unmodified). Pass the returned 'preview_hash' to commit_proposal_promotion — a stale hash (proposal or board changed since) is rejected rather than silently committed.

[MAINTENANCE] Read-only: List all projects — find, browse, or look up your projects and their IDs. Call this first when you have a project name but need its project_id, or to discover which projects exist. Returns [{id, name, sprint, created_at}] newest first.

[SUPPORT] 2ce5bc76 — ROBUST symbol prospecting with a three-rung fallback chain: tries codebase__search_graph FIRST (fast, graph-indexed); when it returns zero results OR the caller flags a mismatch (stale_graph=true), automatically retries via Serena extractor__find_symbol / extractor__find_declaration (AST-accurate, never stale); falls back to a BM25 keyword grep over search_code_semantic as a last resort so the caller NEVER has to notice a miss and switch tools by hand. Each rung is labelled in the result ({rung: 'graph'|'serena'|'semantic', hits:[...], fallback_reason: str?}) so the caller knows which level succeeded. All three legs are best-effort: a missing tunnel, inactive slot, or missing root_dir degrades to the next rung, never a bare error with no diagnostic. d5e60791 — every rung's outcome is recorded under result.rungs.{graph,serena,semantic}: status ('not_attempted'|'skipped'|'attempted'|'succeeded'|'empty'|'error'), attempted_tool/selected_tool, and (on skip/error) a reason/error + error_kind ('dependency_error' vs 'runtime_error') — a missing dependency (e.g. an uninstalled local package) or any other runtime failure in a rung is NEVER silently collapsed into rung='none' with no trace; fallback_reason is always populated when every rung misses. 4b8f083f — when root_dir is a git checkout, the graph rung is ALSO auto-skipped (same as an explicit stale_graph=true, with fallback_reason 'graph_skipped_commit_drift_detected') whenever a cheap local `git rev-list --count` finds real commits since the last index_repository run for this project — no waiting for a _graph_staleness warning from the server, which only fires when a SIBLING process re-indexes, never when nobody re-indexes at all. Pass root_dir to get this protection. Use this instead of calling codebase__search_graph directly whenever you are prospecting for a symbol, function, or class location — it is structurally immune to the class of silent graph-index miss that previously returned wrong line numbers or empty results for real symbols.

[MAINTENANCE] c0168425 — Project-scoped, cutoff-based retention sweep spanning BOTH ai_log_events (meridian.db.ai_log.purge_events_before) and their stored artifacts (meridian.artifact_store.purge_artifacts_before) in one call, with a single receipt. Deletes every event/artifact strictly older than cutoff (an ISO-8601 UTC datetime, e.g. '2025-01-01T00:00:00Z') for the given project. Irreversible — this is a hard bulk delete, not a soft archive (call export_ai_log / export_ai_log_artifacts first if the data needs to survive the sweep). Returns {project_id, cutoff, events_deleted, artifacts_deleted, purged_at}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] PARALLEL COORDINATION (d3a3a01d): fetch unread messages addressed to a session (oldest first) and mark them read by default. The receive side of send_message. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] W1-J — atomically UPDATE an existing generic pointer's targets/source_type/label IN PLACE (a single UPDATE statement), replacing the delete_sprint_item_pointer + add_sprint_item_pointer workaround the pointer CRUD previously required to 'move' or correct a stored pointer. That two-call workaround is non-atomic: an exception between the delete and the re-add permanently loses the pointer, a concurrent get_sprint_item_pointers call in that window sees ZERO pointers for the item, and the pointer's id/created_at change — breaking anything that referenced it by its stable id (a decision's evidence, an artifact-provenance link). This tool preserves id/project_id/sprint_item_id/created_at exactly and never has a window where the row is absent. At least one of targets/source_type/label is required; an omitted field keeps its CURRENT stored value (pass label explicitly — including null/empty — to change or clear it; omit the key entirely to leave it untouched). When targets IS supplied, the replacement is validated exactly like add_sprint_item_pointer BEFORE the write (same malformed-pointer errors, same target_kind/freshness/repo_root rules — see that tool's description for the full target shape) — a validation failure changes nothing; when targets is omitted, the stored targets are carried over untouched (never re-run through that same filesystem check — a stored pointer's target_kind is a normalized artifact of prior validation, not fresh input to re-verify). Cross-project safe: returns {error} when pointer_id doesn't exist in project_id, exactly like a nonexistent pointer id (never distinguishes a foreign-project pointer from a missing one). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] 7acb8563 — rename a project. Returns the updated project, or {error} if it does not exist. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Invalidate a still-standing proposal gate decision (e.g. new evidence surfaced) so resolve_proposal_gate can be called again. Resets the lane to 'blocked' (fail-safe), snapshots the prior decision into previous_decision / previous_actor / previous_decided_at, and increments reopen_count. Refuses with {error} if the gate was never decided. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] cdd0ef6c — Read-only: list this project's session recovery registry, newest heartbeat first, each with a freshly computed liveness classification (resumable/stale/dead/unknown). Dead rows are omitted by default.

[SUPPORT] efaa918a — STALE-MANIFEST GATING: check whether a wave run opened by start_wave_run is still safe to resume against the LIVE board before you act on its pinned manifest. Re-queries the board across ALL non-done statuses (pending, todo, in_progress, provisional_complete, indeterminate, failed, skipped, pushed) via build_board_snapshot — NEVER status='pending' alone, which is the exact b763d2ba bug class (a sibling-claimed in_progress item looks like it vanished). Fails CLOSED with SPECIFIC, actionable reasons the moment the live board differs from the pinned manifest in ANY of: revision_hash mismatch (added/removed items, status/dependency/resource/pointer changes — reusing diff_board_snapshots's added/removed/changed_items shape verbatim as resume_delta), an item's wave membership changed, or an item was newly marked blocker_kind='superseded' (its premise was replaced). Optionally also verifies a handoff token: pass goal_token (+ presented_body to additionally check body-hash binding, efaa918a — closes the 2ee0000c gap where a genuine token could be re-attached to an edited body and still verify). Token outcomes keep the four existing distinct meanings from verify_handoff_token (not_found/wrong_project are real spoofing signals; already_consumed/expired usually mean a sibling already acted) PLUS the new body_mismatch (a real spoofing signal — genuine token, edited body). Read-only w.r.t. the wave run itself (does not advance wave_run status — call advance_wave_run_status separately once resumable). Returns {resumable, wave_run_id, status, resume_delta, pinned_revision_hash, live_revision_hash, token_check} on success, or {error, resumable: false, reasons, resume_delta, token_check} naming exactly what is stale. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Propose a replacement for an anchored section of an agent template doc (CLAUDE.md or AGENTS.md). Does NOT write the file directly — it creates a human-in-the-loop request carrying a diff preview. A human approves it in the dashboard, then Meridian replaces that section and stages the file for the next checkpoint commit. 'anchor' is the section name between the MERIDIAN:ANCHOR:START/END comments. (ROADMAP/DECISIONS/DEVLOG are append-only and not replaceable.) Pass force=true from a human planning session (claude.ai) to skip the HITL and apply the replacement directly; autonomous executor sessions should omit force so the diff stays gated. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] PARALLEL COORDINATION (d3a3a01d): enqueue an actor-model message to another session (session_messages table). 'Done with X, you do Y' between parallel agents. The recipient reads with receive_messages. A2A-compatible. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] Read-only: List active sessions for a project. Useful for planning chat to see what's currently running before filing new sprint items.

[MAINTENANCE] Record a code-graph snapshot for a session (node count, edge count, hotspot count, file churn). Call at session start and end to enable get_graph_diff comparisons. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Search public social-media / discussion content — a REAL external lookup (keyless), sibling to paper_search but for social discussion rather than academic papers. Currently one keyless source via the 'source' param: 'hn' (default; Hacker News via the Algolia HN Search API, story submissions only, not raw comments). Returns {query, count, results:[{title, authors, summary, published, url, discussion_url, points, num_comments, hn_id, ...}]}.

[SUPPORT] Split a sprint item into multiple smaller items. The original is closed (skipped) and N new items are created with split_from referencing the original. Returns list of new items. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] PARALLEL COORDINATION (c35370cc): persist a per-task intermediate result to the session_findings table so it survives session boundaries. Parallel reader agents write findings; an orchestrator or writer agent reads them via get_findings. Unlike save_finding (which creates a research note), this is a lightweight key→content store for agent-to-agent handoff of intermediate work. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Add a child sprint item under an existing parent item. Inherits the parent's version. Status starts as pending. Rejects if the parent is already done, failed, or skipped. Pass owner='human' or owner='ai' to build a mixed-ownership task chain: owned subtasks added in sequence become a strict chain (each depends on the previous owned sibling), and completing one auto-advances ownership — an AI→human step files a HITL handoff, a human→AI step un-blocks the next AI subtask. The parent stays in_progress until all subtasks are terminal. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] Read-only: Natural-language search that returns a short, CITED answer (which notes/items it drew from) synthesized over the same retrieval as search_all — not just a list of matches. Uses a cheap Haiku call when ANTHROPIC_API_KEY is set, with a deterministic fallback to the raw results (synthesized=false) otherwise. Returns {query, answer, cited, synthesized, results}.

[MAINTENANCE] W1-I — hand a LIVE in_progress claim on a sprint item off to a different actor/session directly, without a reset-to-pending-then-reclaim cycle. The item's status never leaves in_progress, so there is no window where a third session could see it as pending and race to claim it out from under the intended recipient — only actor/claimed_at (and, best-effort, the underlying file/symbol resource locks) move to the new owner. Only the session recorded as the item's current actor may transfer its own claim away — a mismatch is refused (NOT_CLAIM_OWNER) unless force=true is explicitly passed. When to_session_id is given and the item declares touches_resources, each declared file:/symbol: lock is released under session_id and re-acquired under to_session_id via the same claim_file/claim_symbol machinery claim_sprint_item itself uses (a symbol: resource is released but not auto-reclaimed — re-acquiring a real AST-resolved range needs the file's current content, which this call doesn't have; the receiving session should claim_file(symbol=..., content=...) itself for those). Returns a structured {blocked: true, error: ...} dict (NOT_IN_PROGRESS / NOT_CLAIM_OWNER / SAME_ACTOR / RACE_LOST) rather than raising when it can't proceed; on success returns {item_id, prior_actor, prior_claimed_at, new_actor, transferred_resources, released_only_resources, item}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[MAINTENANCE] f1e0df55 — Read-only: ONE layered diagnostic snapshot of your tunnel/connectors, separating what's SAVED in the dashboard from what's ACTUALLY running so a saved-but-not-yet-applied setting is never reported as active. Per slot (fs/code/extract/ppt/word/dc/docs/zotero/outputs/debug): dashboard_configured (persisted), process_active (live server-side socket), external_child_state (last client-reported lifecycle state), last_error, and exact remediation text — plus one of five distinct states: healthy, stale, degraded, quarantined, or restart_required (persisted config and observed runtime disagree). Also reports the server-side tool routing cache size, a config generation + manifest_hash fingerprint for drift detection, and whether a tools/list re-discovery is pending. Includes a run_id + timestamp for correlating with support requests. Tokens/credentials are redacted. Requires an authenticated hosted tenant (tunnel mode) — self-hosted callers with no tenant get an empty, unauthenticated-shaped snapshot.

[SUPPORT] Confirm or invalidate the assumption a pinned decision rests on, in one call — no phase switching. Stamps the decision's assumption_status (confirmed|invalidated), saves a code-anchored note with your finding, and when confirmed=false fires a BLOCKING HITL so work depending on the decision pauses for human judgment. Use the moment you discover whether an assumption holds (a planning-session prospect moment). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] 0e973e52 — run the project's stored test_cmd on YOUR local machine via the tunnel and return a REAL, structured result — not self-reported. Fields: {exit_code, passed, failed, stdout_tail, stderr_tail, status, timed_out}. Returns {status: 'not_configured'} (never an error) when no test_cmd is set; call set_executor_config(test_cmd='pixi run test') first. Requires an active `meridian --tunnel`; the hosted server has no access to your machine (same architectural class as ingest_document / search_code_semantic / search_outputs — decision 0dedff91). Per-project: only runs when test_cmd is configured for that project. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.

[SUPPORT] dffcde86 (a03c0eeb) — Read-only: list active_worktrees rows still marked active in the DB (removed_at IS NULL) whose owning sprint item has reached a terminal status (done/skipped/failed/pushed) or whose owning session is closed/archived — the real disk-cleanup candidates the periodic sweep (worktree_cleanup.sweep_stale_worktrees) reclaims. On hosted Meridian the POST /worktrees/sweep endpoint is an explicit filesystem no-op (hosted has no access to the caller's disk, so there is nothing there to remove from disk) — this tool is the DB-only, hosted-safe way to see which registry rows are stale either way; actually clearing a row still requires the self-hosted sweep or an explicit DELETE /projects/{id}/worktrees/{worktree_id}. Omit project_id to scope across every project, matching the server-wide periodic sweep's own query.