Middleware, not a framework

Every transport cwp uses belongs to something else. DDEV runs the container, WP-CLI talks to WordPress, and the host moves the files. What cwp adds is the decision about what may move, in which direction, and what has to be true before and after.

That is a constraint with teeth, and three rules fall out of it.

It never reimplements what a tool already does

The clearest case is URL rewriting. WordPress stores serialised data, and a page builder stores element trees as serialised JSON in postmeta — so a sed over a SQL dump corrupts every array whose string lengths it changes. cwp always calls wp search-replace, which is WordPress’s own answer to its own storage format.

The same reasoning covers the container, the transfer and the backup. A tool that reimplemented one of those would have to be right about it forever; a tool that calls it inherits somebody else’s correctness.

It has no plugin system

There is no discovery mechanism, no loadCommands(), and no third-party providers or builders. The command surface is a literal array in the source, and adding a command is one entry plus one module.

Extensibility is covered by hooks — shell scripts cwp runs at named points, which you write, which run in your shell, and which cwp does not have to define an interface for. Providers and builders are compiled-in implementations of closed interfaces, chosen by configuration rather than found at runtime.

It talks to no control panel

cwp uses your host’s own CLI or plain ssh. It calls no hosting API, provisions nothing, and holds no credential of its own beyond what those tools already have. It also fetches no premium plugins and stores no licence keys — a tool that held your licence keys would be a tool you had to trust with them.