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 constraint has 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, 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.

Hooks cover extensibility: shell scripts cwp runs at named points. You write them, they run in your shell, and cwp defines no interface for them. Providers and builders are implementations of closed interfaces, compiled in and 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 plugin licence keys. A tool that held those would be a tool you had to trust with them. cwp fetch is deliberately the command that brings down what you already have rather than what you have paid for.