feat!: remove capability apply

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

@@ -1,83 +0,0 @@
-# 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.