docs(prd): draft capability apply removal
This commit is contained in:
@@ -0,0 +1,83 @@
|
||||
# PRD prd-new: Remove capability apply
|
||||
|
||||
- **Status:** Draft
|
||||
- **Author:** Codex
|
||||
- **Created:** 2026-06-25
|
||||
- **Issue:** #281
|
||||
|
||||
## Summary
|
||||
|
||||
Remove the capability remediation path from the supervise plane. Agents will
|
||||
no longer receive a `capability-block` MCP tool, operators will no longer see
|
||||
capability Dockerfile proposals in `supervise`, and the Docker-specific
|
||||
capability apply module will be deleted.
|
||||
|
||||
## Problem
|
||||
|
||||
The capability apply flow asks an agent to propose a replacement Dockerfile,
|
||||
then expects the host to rebuild and resume the bottle after operator approval.
|
||||
That behavior is difficult to implement correctly across Docker,
|
||||
smolmachines, and macOS Container backends. The current tree reflects that:
|
||||
the Docker apply module still exists, but the supervisor has the actual apply
|
||||
call commented out and capability proposals are only acknowledged/archived.
|
||||
|
||||
Keeping the half-disabled path makes the public MCP surface misleading. Agents
|
||||
can still ask for a capability change even though approval does not reliably
|
||||
produce a rebuilt bottle, and new backends have to carry compatibility code for
|
||||
a feature that is not in active use.
|
||||
|
||||
## Goals / Success Criteria
|
||||
|
||||
- The supervise sidecar does not advertise `capability-block`.
|
||||
- `tools/call` rejects `capability-block` as an unknown tool.
|
||||
- Host-side proposal validation no longer accepts capability proposals.
|
||||
- The supervisor TUI no longer special-cases capability proposal approval,
|
||||
archive behavior, file suffixes, or apply errors.
|
||||
- The Docker `capability_apply.py` module is removed.
|
||||
- The unused agent current-config Dockerfile mount is removed from the
|
||||
supervise plan and Docker compose renderer.
|
||||
- Unit tests cover the reduced supervise tool set and unknown-tool behavior.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Removing egress proposal tools, gitleaks allow proposals, token allow
|
||||
proposals, or `list-egress-routes`.
|
||||
- Designing a replacement capability remediation workflow.
|
||||
- Rewriting historical PRDs or research notes that describe the old design.
|
||||
- Changing manual operator workflows such as editing bottle manifests,
|
||||
rebuilding images, or restarting bottles outside the supervise MCP path.
|
||||
|
||||
## Design
|
||||
|
||||
The supervise plane becomes egress-only for agent-initiated configuration
|
||||
changes. The exported tool constants and `TOOLS` tuple keep egress, gitleaks,
|
||||
token allow, and list routes entries, but drop the capability constant. Proposal
|
||||
deserialization rejects any queued `capability-block` file as an unknown tool,
|
||||
matching how unknown proposal kinds are already handled.
|
||||
|
||||
The sidecar deletes the `capability-block` tool definition and removes the
|
||||
`dockerfile` payload mapping. `validate_proposed_file` only validates egress
|
||||
route proposals; any other tool value raises the existing JSON-RPC invalid
|
||||
params error. This keeps the failure mode explicit for older agents that try to
|
||||
call the removed tool.
|
||||
|
||||
The operator CLI removes the placeholder capability apply error, the commented
|
||||
apply import/call, the `.dockerfile` suffix branch, and the special archive on
|
||||
approval. Since the sidecar no longer queues capability proposals, existing
|
||||
stale capability proposal files are ignored by discovery when they fail
|
||||
`Proposal.from_dict`.
|
||||
|
||||
The Docker-specific `backend/docker/capability_apply.py` file is deleted. The
|
||||
supervise plan no longer stages a `current-config` directory, and the Docker
|
||||
compose renderer no longer mounts `/etc/bot-bottle/current-config` into the
|
||||
agent container.
|
||||
|
||||
## Testing strategy
|
||||
|
||||
- Update supervise queue tests so their default proposal uses an egress tool.
|
||||
- Update sidecar tests to assert `capability-block` is absent from
|
||||
`tools/list` and rejected by `tools/call`.
|
||||
- Update supervisor CLI tests to remove capability archive/no-audit
|
||||
expectations and keep coverage for egress, gitleaks, and token allow paths.
|
||||
- Update compose and supervise prepare tests to assert no current-config mount
|
||||
or staging directory is created.
|
||||
Reference in New Issue
Block a user