Add PHP / WordPress / Composer / PHPUnit / ddev coverage to rewrite registry

The v3 thin hook in 0.35 is great, and pushing all the rewrite logic into rtk rewrite was the right move. One gap I keep hitting: the registry is currently very thin on the PHP/WordPress side of things.

Context

$ rtk --version
rtk 0.35.0

Hook installed via rtk init -g (v3, delegates to rtk rewrite). Stack: PHP / WordPress / Bedrock / ddev, daily.

The gap

I went through the commands I actually run on a typical WordPress day. They all return exit code 1 (no rewrite), even though they dump exactly the kind of verbose, structured output the rest of rtk is built around.

Reproduction

$ rtk rewrite "wp plugin list"                ; echo $?   # 1
$ rtk rewrite "wp post list"                  ; echo $?   # 1
$ rtk rewrite "wp option get siteurl"         ; echo $?   # 1
$ rtk rewrite "wp plugin activate akismet"    ; echo $?   # 1
$ rtk rewrite "vendor/bin/phpunit"            ; echo $?   # 1
$ rtk rewrite "phpunit tests/Foo.php"         ; echo $?   # 1
$ rtk rewrite "phpcs --standard=WordPress src"; echo $?   # 1
$ rtk rewrite "phpcbf src"                    ; echo $?   # 1
$ rtk rewrite "php -l file.php"               ; echo $?   # 1
$ rtk rewrite "composer test"                 ; echo $?   # 1
$ rtk rewrite "composer dump-autoload"        ; echo $?   # 1
$ rtk rewrite "ddev composer install"         ; echo $?   # 1
$ rtk rewrite "ddev wp plugin list"           ; echo $?   # 1
$ rtk rewrite "npm test"                      ; echo $?   # 1   # see "Bonus" below

For comparison, the neighbours that already work:

$ rtk rewrite "git status"           # 0  -> rtk git status
$ rtk rewrite "composer install"     # 0  -> rtk composer install
$ rtk rewrite "npm run build"        # 0  -> rtk npm run build

Suggested mapping

These fit cleanly into the existing summary / err / test categories. I can send a PR against src/discover/registry.rs if you confirm conventions.

wp (WP-CLI)

Listing and read commands -> rtk summary. Output is usually a giant table or JSON blob, but only the headline state matters in an LLM context.

• wp plugin list, wp theme list, wp post list, wp user list, wp option list, wp term list, wp comment list, wp media list, wp site list
• wp option get, wp config get
• wp cron event list, wp cron schedule list
• wp db tables, wp db query, wp db search
• wp search-replace, wp export, wp eval, wp eval-file

Side-effect commands -> rtk err. The interesting output is errors and warnings, the rest is noise.

• wp plugin {activate,deactivate,install,update,delete,uninstall}
• wp theme {activate,install,update,delete}
• wp cache {flush,delete}, wp transient delete
• wp rewrite {flush,hard}
• wp core {update,update-db,verify-checksums}
• wp db {optimize,repair,check,clean}
• wp media {regenerate,import}
• wp option {update,delete}

Composer

• composer test, composer test:*, composer run test* -> rtk test
• composer dump-autoload, composer require, composer remove, composer update, composer run-script, composer run * -> rtk err (composer install is already covered. The same logic should extend to its siblings.)

PHPUnit / PHPCS / PHPCBF

• phpunit, vendor/bin/phpunit, ./vendor/bin/phpunit -> rtk test
• phpcs, vendor/bin/phpcs, phpcbf, vendor/bin/phpcbf -> rtk err

Plain PHP CLI

• php -l <file> (lint) -> rtk err
• php -r '<expr>' (one-liner) -> rtk err (mostly fatal/notice noise)

DDEV (and friends: lando, wp-env, ...)

DDEV wraps any command as ddev <wrapped>. The cleanest fix is to strip the ddev prefix and recurse so every existing rule auto-applies. The same trick would cover lando, wp-env, and any other dev-container CLI.

Examples that should "just work" if recursion is supported:

ddev composer install   -> rtk composer install
ddev wp plugin list     -> rtk summary wp plugin list
ddev phpunit            -> rtk test phpunit
ddev npm run build      -> rtk npm run build

Bonus: npm test

$ rtk rewrite "npm test"      -> exit 1 (no rewrite)
$ rtk rewrite "npm run build" -> rtk npm run build

npm test is by far the most common npm invocation in the wild. Worth catching as rtk test, or at minimum mirroring the npm run build behaviour for parity.

Why it matters

WP-CLI alone has 100+ subcommands, almost all of them dumping tables or noisy logs to stdout. Right now a PHP/WordPress user leaves a big chunk of potential token savings on the floor compared to someone working in JS, Rust, or Go.

I'm currently working around this with a hand-maintained block in front of rtk rewrite in my Claude Code hook. The v3 hook itself says it best: "all rewrite logic lives in rtk rewrite, which is the single source of truth". So I'd rather upstream this.

Happy to send a PR. Just point me at src/discover/registry.rs and let me know your preferred granularity.