v0.13.0

Security and observability (BREAKING)

• BREAKING: Writes now require a durable audit intent before contacting the upstream platform. If the audit database cannot accept the intent, the write fails closed; a failed final audit update leaves an unresolved pending intent.
• Real writes now commit a durable pending audit intent before the upstream call. If audit storage is unavailable, the write does not start; a failed final update leaves a visible pending intent and blocks further writes in that process.
• Audit rows retain outcome metadata instead of full business responses. AIOPS_WORKFLOW_ID links calls across a workflow; optional AIOPS_TELEMETRY=1 emits metadata-only JSON events and AuditEngine.health() reports audit failures and pending intents.

v0.12.0

Fixed

• The MCP server moved from a top-level mcp_server package to
  postgres_aiops.mcp_server. Every AIops tool used to ship its own top-level
  mcp_server, so installing two of them into one environment merged the two
  into one package: postgres-aiops-mcp could start another tool's server, and
  postgres-aiops undo wrote audit and undo rows into the other tool's home
  directory. Installs through uvx, the Claude Code plugin or the OpenClaw
  bundle were isolated and unaffected. The postgres-aiops-mcp command is
  unchanged; only code that imported mcp_server directly must now import
  postgres_aiops.mcp_server.

v0.11.0

Added

• MCP tool annotations derived from each tool's governance risk_level, so
  clients can gate approval from tools/list alone. low tools advertise
  readOnlyHint: true; every other tool advertises readOnlyHint: false and
  destructiveHint: true. The medium tier includes deletes and hard
  power-offs, so a tool is never advertised as non-destructive on the strength
  of its tier. idempotentHint only repeats an explicit declaration. The exact
  level is published in _meta under io.github.AIops-tools/riskLevel. These
  are hints for the client; audit and undo are unchanged.

Fixed

• blocking_lock_chain_rca: the chain root's state was dropped and a missing
  query became "". For a backend that is idle in transaction, rootQuery is
  the last statement it ran, not a running one, so the recommended
  cancel_query had nothing to cancel. Roots now carry rootState and
  rootIdle (true for any idle* state, including plain idle with session-level locks), a missing query stays null, and the action for an
  idle root points at terminate_backend (which rolls the transaction back).

v0.10.3

Fixed

• CLI commands that read the engine without calling an MCP tool now write an
  audit row, as every MCP call does: they run through the same @governed_tool
  harness, budget and runaway guard included. Before, an operator's CLI reads
  left no trace in audit.db, contrary to the documented guarantee that MCP
  and CLI are audited alike. A test fails if any engine command escapes it.

v0.10.2

Changed

• The ClawHub bundle plugin moved from @aiops-tools/postgres-aiops to
  @zw008/postgres-aiops, matching the publisher the skill has always been under.
  ClawHub cannot move a package between scopes — the scope is the publisher
  identity — so this is a republish under the new name; the old name is
  withdrawn. Install with:
  openclaw plugins install clawhub:@zw008/postgres-aiops. Nothing about the Python
  package, the CLI, the MCP server or the Claude Code plugin changes.

v0.10.1

Added

• The OpenClaw install path is documented. The ClawHub bundle channel went
  live but neither the README nor this skill said how to install from it:
  openclaw plugins install clawhub:@aiops-tools/postgres-aiops. States the uvx
  prerequisite (without it the skill installs but reports Visible to model: no) and that the MCP server is pinned to this exact release.
• Where an exported master password lives is now stated next to the
  instruction to export it: readable by every process the shell starts, and
  kept in shell history.

v0.10.0

Added

• Installable as a Claude Code plugin. .claude-plugin/plugin.json plus a
  root .mcp.json make this repo a plugin, so /plugin install postgres-aiops@aiops-tools
  delivers the skill and registers the MCP server in one step. The server is
  pinned to the exact package version the manifest declares, so an audit row
  stays traceable to the code that produced it. Nothing about the tool itself
  changed — the CLI and the standalone MCP server work exactly as before.
• Installable from ClawHub as an OpenClaw bundle plugin (@aiops-tools/postgres-aiops): one install delivers the skill and its MCP
  server, pinned to this exact release. clawhub.ai/plugins.

Fixed

• The skill was invisible to the model in OpenClaw. Its metadata
  declared requires.config (OpenClaw reads that as config keys, not file
  paths, so it can never be satisfied), requires.env and requires.bins
  naming our own CLI — which a plugin user never has on PATH — plus a
  primaryEnv that turned a config path into an API-key prompt. Measured on
  OpenClaw 2026.6.35: Visible to model: no. It now requires
  anyBins: [postgres-aiops, uvx] — either one suffices — with every variable kept
  in optional.env (still declared, no longer a load gate), which the same
  command reports as Visible to model: yes.

v0.9.0

Fixed

• An undetermined outcome no longer exits as a plain failure. A write whose response was lost carries both error and outcomeUnknown, and the harness deliberately judges unknown first when writing the audit row — the change may have taken effect, so a blind retry could apply it twice. The CLI guard judged error first, so the audit said "may have taken effect" while the exit status told a script it had not happened. The two layers now agree (exit 2, not 1), and a test pins the ordering so it cannot silently flip back.
• The CLI reported a refused or failed governed write as a success. 10 write call sites printed the governed twin's payload and exited 0 whatever it said — and @tool_errors flattens every refusal, guard rejection and upstream failure into {"error": ...} rather than raising, so nothing downstream of a && chain or a CI step could tell a blocked write from a landed one. The dry-run path already exited non-zero, which made the asymmetry worse: the preview was stricter than the write it previews. Results now route through a checked() helper — exit 1 on an error payload, exit 2 on an undetermined outcome, unchanged on success. This defect class had been fixed repo-by-repo several times and kept coming back; an audit across the whole line found it live in 18 of the 24 tools at once (87 call sites), so each tool now carries an invariant test that fails if any future CLI command prints a governed result without checking it.

v0.8.0

Fixed

• undo apply replays against the target the original write ran on. It dispatched the inverse against whatever target the caller named — in practice the config's first entry — while the write's own target sat unused in the undo record. On a multi-target config the inverse therefore ran against the wrong host; it only looks harmless because the resource usually is not there, but two hosts holding the same name and the inverse succeeds on the wrong one, silently. An explicitly named target still wins. Line-wide: all 24 copies had the identical defect. Caught live in container-host-aiops, where a stop recorded against a Podman target replayed against a Portainer one.
• Undoing an ALTER SYSTEM SET no longer leaves the parameter pinned. The inverse wrote the prior value back with another ALTER SYSTEM SET, so a parameter that had no postgresql.auto.conf entry beforehand ended up with one. The number was right, but postgresql.auto.conf overrides postgresql.conf, so the "undo" silently shadowed the operator's config file from then on — a later edit there would have no effect. update_setting now records where the value came from (pg_settings.sourcefile), and the inverse is ALTER SYSTEM RESET unless the parameter was already carried by auto.conf. Live-verified on PostgreSQL 16.14 in both directions, checking postgresql.auto.conf itself after each undo.

Added

• update_setting(reset=True) / remediate set <name> --reset — ALTER SYSTEM RESET a parameter, dropping its postgresql.auto.conf entry so postgresql.conf or the built-in default applies again. This is what the corrected undo replays.
• priorState on a setting change now carries source and pinnedInAutoConf, so a caller can see whether a value was explicitly pinned or inherited.

v0.7.0

Changed (BREAKING)

• Requires MCP SDK 2.0 (mcp[cli]>=2.0,<3.0). mcp.server.fastmcp no longer exists in 2.0; the server is now built with MCPServer and reports its package version in the stdio handshake.

Fixed

• undo apply works from the CLI. Every write tool is imported lazily inside its own CLI command, so a CLI-driven undo ran in a process where the inverse tool was never registered and failed with "inverse tool is not registered" — for every write tool. Only the MCP entry point, which imports the whole server, worked. Found while live-verifying against a real cluster.
• An undetermined outcome is audited unknown, not ok. The harness only classified a result as undetermined when the payload also carried an error key, so a write that looked successful but had not been confirmed was recorded as a success.