← Back to Plugins
Tools

Npcink Ai Client Adapter

muze-page By muze-page 👁 62 views ▲ 0 votes

Npcink OpenClaw Adapter WordPress plugin

GitHub

Configuration Example

{
  "include_log_contents": false,
  "include_active_plugins": true,
  "include_inactive_plugins": false,
  "include_plugin_updates": true,
  "include_must_use_plugins": true,
  "include_dropins": true,
  "max_plugins_per_group": 100
}

README

# Npcink AI Client Adapter

Npcink AI Client Adapter is a thin AI client channel plugin for WordPress.

It gives OpenClaw-compatible and similar AI clients one WordPress REST namespace that can:

- read Npcink Governance Core capability guidance;
- run approved direct-read abilities through WordPress Abilities API;
- create Core proposals for write or destructive operations;
- orchestrate one user-triggered approve-and-execute action through Core.

AI clients should connect through Adapter. Npcink Governance
Core is the governance service behind Adapter. Core remains the approval,
preflight, and audit truth source; Adapter exposes the productized channel
actions and does not rely on controlling any specific external AI client.

It does not define abilities, store approval state, run workflows, expose a
generic approve/reject proxy, or execute final write mutations without Core
approval, commit-preflight, and an explicit Adapter execution profile.

When Core or Adapter blocks a plan handoff, rejected proposal, or preflighted
execution, error responses may include `data.operator_feedback`. Clients should
display that object to the operator and create a revised new proposal instead
of retrying execution against the blocked proposal id. Core remains the
governance truth.

AI Client Adapter consumer readiness is complete as of Adapter governance commit
`b81dc2a`. Productized clients should use Adapter as the only entry point.
See [OpenClaw Adapter Consumer Readiness](docs/openclaw-adapter-consumer-readiness.md)
for the dependency snapshot, verified routes, closed loop, and next-stage
execution allowlist rules.

Batch plan execution is intentionally narrow. Adapter can execute
`input.write_actions[]` only after Core approval and commit-preflight, and only
when every action targets the current execution allowlist
(`npcink-abilities-toolkit/trash-post`, `npcink-abilities-toolkit/create-draft`,
`npcink-abilities-toolkit/update-post`, `npcink-abilities-toolkit/set-post-seo-meta`,
`npcink-abilities-toolkit/set-post-slug`, `npcink-abilities-toolkit/set-post-terms`,
`npcink-abilities-toolkit/delete-term`, `npcink-abilities-toolkit/patch-post-content`,
`npcink-abilities-toolkit/update-post-blocks`,
`npcink-abilities-toolkit/patch-setting-value`,
`npcink-abilities-toolkit/update-media-details`,
`npcink-abilities-toolkit/optimize-media-asset`,
`npcink-abilities-toolkit/replace-media-file`,
`npcink-abilities-toolkit/restore-media-backup`,
`npcink-abilities-toolkit/adopt-cloud-media-derivative`,
`npcink-abilities-toolkit/rename-media-file`,
`npcink-abilities-toolkit/delete-media-permanently`,
`npcink-abilities-toolkit/reply-comment`, `npcink-abilities-toolkit/trash-comment`,
`npcink-abilities-toolkit/approve-comment`). See
[OpenClaw Batch Execution Policy](docs/openclaw-batch-execution-policy.md).
Batch execution responses expose selected/submitted/executed/failed counts,
per-action status, execution profile, idempotency key, Core preflight evidence,
retryability, and `operator_next_action` so product surfaces such as Toolbox can
render approved batch outcomes without owning a queue or write executor.

## Runtime Boundary

Layer ownership:

| Layer | Plugin | Responsibility |
| --- | --- | --- |
| Ability layer | `npcink-abilities-toolkit` | Registers canonical abilities, schemas, callbacks, permissions, and dry-run previews. |
| Governance layer | `npcink-governance-core` | Discovers abilities, classifies risk, stores proposals, handles approval/preflight, and audits governance decisions. |
| Channel layer | `npcink-ai-client-adapter` | Gives AI clients a small REST adapter that calls Core and WordPress Abilities API. |

## Suite Distribution

Npcink AI Client Adapter is the productized entry plugin for the Npcink AI suite,
but distribution does not merge runtime ownership. The suite package ships
Adapter, Core, and the Abilities Toolkit as separate WordPress plugin zips and
keeps their REST namespaces, plugin headers, data stores, and tests separate.

The current Adapter plugin header declares `Requires Plugins:
npcink-abilities-toolkit` because `npcink-abilities-toolkit` is the confirmed
WordPress.org dependency slug. Core and Adapter slugs are still treated as
distribution contract values until their public slugs are finalized; runtime
readiness is detected through REST routes and public functions instead of
display names.

Adapter `/health` and `/help` remain available when dependencies are missing.
Routes that require Core or WordPress Abilities API fail closed with
`npcink_openclaw_adapter_missing_dependency`. See
[Npcink AI Suite Distribution Contract](docs/distribution-contract.md).

When Core and the Abilities Toolkit expose their admin-only runtime contract
endpoints, Adapter also includes a bounded `dependency_contracts` summary on
`/health`, `/help`, and `/connection/manifest`. The summary verifies the Core
`npcink_governance_core_contract.v1` and Toolkit
`npcink_abilities_toolkit_contract.v1` schema versions against Adapter's
declared minimum floors, then carries only compatibility and boundary fields,
such as Core's `provider_secret_storage=false` posture and Toolkit's
`host_governed_writes=true` write control. It does not copy Core proposal,
approval, or audit state, and it does not expose secrets.

## REST Surface

All routes require `manage_options` through normal WordPress REST
authentication, such as an administrator Application Password.

- `GET /wp-json/npcink-openclaw-adapter/v1/health`
- `GET /wp-json/npcink-openclaw-adapter/v1/help`
- `GET /wp-json/npcink-openclaw-adapter/v1/capabilities`
- `GET /wp-json/npcink-openclaw-adapter/v1/proposals/{proposal_id}`
- `POST /wp-json/npcink-openclaw-adapter/v1/run-read-ability`
- `POST /wp-json/npcink-openclaw-adapter/v1/read-requests`
- `GET /wp-json/npcink-openclaw-adapter/v1/read-requests`
- `GET /wp-json/npcink-openclaw-adapter/v1/read-requests/{request_id}`
- `GET /wp-json/npcink-openclaw-adapter/v1/proposals/{proposal_id}/media-optimization-readiness`
- `POST /wp-json/npcink-openclaw-adapter/v1/proposals`
- `POST /wp-json/npcink-openclaw-adapter/v1/proposals/from-plan`
- `POST /wp-json/npcink-openclaw-adapter/v1/execute-approved-proposal`
- `POST /wp-json/npcink-openclaw-adapter/v1/proposals/{proposal_id}/execute`
- `POST /wp-json/npcink-openclaw-adapter/v1/proposals/{proposal_id}/approve-and-execute`

Adapter does not expose direct-read shortcut routes, workflow recipe routes,
provider/model smoke routes, or Cloud/media derivative façade routes. Use
`POST /run-read-ability` for approved reads, Core proposal routes for governed
writes, and `npcink-cloud-addon` for Cloud runtime transport.
- `GET /wp-json/npcink-openclaw-adapter/v1/proposals`
- `GET /wp-json/npcink-openclaw-adapter/v1/proposals/{proposal_id}`
- `POST /wp-json/npcink-openclaw-adapter/v1/proposals`
- `POST /wp-json/npcink-openclaw-adapter/v1/proposals/from-plan`
- `POST /wp-json/npcink-openclaw-adapter/v1/execute-approved-proposal`
- `POST /wp-json/npcink-openclaw-adapter/v1/proposals/{proposal_id}/execute`
- `POST /wp-json/npcink-openclaw-adapter/v1/proposals/{proposal_id}/approve-and-execute`
- `POST /wp-json/npcink-openclaw-adapter/v1/proposals/{proposal_id}/approve`
- `POST /wp-json/npcink-openclaw-adapter/v1/proposals/{proposal_id}/reject`
- `POST /wp-json/npcink-openclaw-adapter/v1/proposals/{proposal_id}/commit-preflight`

GET shortcut query parameters are forwarded as ability `input`. For example,
`/media?per_page=10&has_empty_alt=1` becomes read input for
`npcink-abilities-toolkit/list-media`.

Diagnostics shortcuts are Adapter aliases over existing direct-read abilities
from `npcink-abilities-toolkit`; Adapter does not collect these facts itself.
`wp-diagnostics-summary` is only a quick overview. P0/P1/P2 troubleshooting
detail shortcuts call `npcink-abilities-toolkit/wp-ops-diagnostics-detail`.

Default diagnostics detail input is:

```json
{
  "include_log_contents": false,
  "include_active_plugins": true,
  "include_inactive_plugins": false,
  "include_plugin_updates": true,
  "include_must_use_plugins": true,
  "include_dropins": true,
  "max_plugins_per_group": 100
}
```

For deep plugin conflict troubleshooting, use
`GET /wp-json/npcink-openclaw-adapter/v1/plugin-conflict-diagnostics` or send the
equivalent input:

```json
{
  "include_log_contents": false,
  "include_active_plugins": true,
  "include_inactive_plugins": true,
  "include_plugin_updates": true,
  "include_must_use_plugins": true,
  "include_dropins": true,
  "max_plugins_per_group": 200
}
```

When the operator explicitly asks to inspect logs, use `recent-error-log-tail` or
send the equivalent input:

```json
{
  "include_log_contents": true,
  "tail_lines": 50,
  "severity": ["fatal", "error", "warning"],
  "since_minutes": 1440
}
```

When `include_log_contents=false`, log contents are not missing; mark them as
not explicitly requested. Clients should use `error_log.summary` for
`fatal_count`, `error_count`, `warning_count`, `deprecated_count`,
`notice_count`, `summary_source`, and `error_log.summary.by_severity` even when
contents are not included. Only display `error_log.tail_entries` or `contents`
after the user explicitly asks for logs. Inactive plugin rows are not requested
by default; show them as default not requested, not missing. Plugin details are
grouped by `plugins.active`, `plugins.inactive`, `plugins.update_available`,
`plugins.must_use`, and `plugins.dropins`, with `plugins.groups_included` and
`plugins.max_plugins_per_group` describing which groups were requested. The
compatibility `contents` array is only redline text for display. The
diagnostics abilities own redaction and schema boundaries. Adapter does not
read arbitrary files, expose database names/table names, collect secrets,
invent diagnostics data, or mix Npcink runtime, MCP, or cloud state into the
WordPress diagnostics mapping.

Content shortcuts pass query parameters through to the underlying ability input,
including the current `npc

... (truncated)
tools

Comments

Sign in to leave a comment

Loading comments...