36 lines
1.4 KiB
Markdown
36 lines
1.4 KiB
Markdown
# Ops MCP workspace tools release
|
|
|
|
This release updates two already registered deploy-runner components. It does
|
|
not add a component and does not change the deploy runner.
|
|
|
|
Deploy order:
|
|
|
|
1. Tasker restores full card reads and adds the narrow project-create and
|
|
attachment adapter intents. It also exposes the two new scopes in the
|
|
existing Tasker agent settings UI.
|
|
2. Ops Agent publishes the three MCP tools, mints independent Ops and
|
|
Ontology credentials from one setup code, and installs two separate MCP
|
|
servers through npm package 0.1.3.
|
|
|
|
The builder emits, for each artifact:
|
|
|
|
- a deterministic tgz;
|
|
- a predecessor SHA-256 file for every replaced production path;
|
|
- a new-path file for paths that must not exist before apply.
|
|
|
|
Operators must verify both companion files before plan. The deploy runner
|
|
then provides the existing component backup, compose rebuild/recreate,
|
|
healthcheck, state registration, and rollback behavior.
|
|
|
|
Security boundaries:
|
|
|
|
- no raw Tasker API;
|
|
- no delete/archive tool;
|
|
- project creation requires project:create, an agent-scoped token, existing
|
|
workspace entitlement, and Tasker workspace-admin revalidation;
|
|
- attachments accept explicit base64 bytes only, max 5 MiB, and use Tasker's
|
|
existing FileAsset/S3 quota and dedup path;
|
|
- Ops and Ontology tokens have distinct persisted purposes and cannot be used
|
|
against the other endpoint;
|
|
- Ontology stays a separate read-only MCP.
|