bot-bottle/docs/prds/prd-new-remove-capability-apply.md

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.