Composer package rename/autoload break dev-main consumers outside WordPress

[lezama]

Summary

After updating a downstream app to agents-api main, two Composer-level issues showed up:

1. composer.json now names the package wordpress/agents-api, while existing downstreams still require automattic/agents-api. Updating automattic/agents-api:dev-main now fails because that package no longer exists at the default branch.
2. The new package metadata autoloads agents-api.php via autoload.files. That entrypoint contains defined( 'ABSPATH' ) || exit;, so Composer CLI tools that load vendor/autoload.php outside WordPress exit silently.

Repro

In a downstream plugin requiring current wordpress/agents-api:dev-main:

php -r 'require "vendor/autoload.php"; echo "after autoload\n";'
./vendor/bin/phpunit --version

Both commands exit 0 without printing the expected output because agents-api.php exits before the CLI command runs.

Composer resolution also fails for downstreams that still require the old package name:

Root composer.json requires automattic/agents-api dev-main, found automattic/agents-api[dev-main] in the lock file but not in remote repositories

Expected

• If the rename is intentional, wordpress/agents-api should likely replace/provide automattic/agents-api for self.version so existing downstream dev-main consumers continue to resolve during migration.
• Composer autoload should not terminate non-WordPress CLI processes. Options: return when ABSPATH is missing, avoid autoload.files for the plugin bootstrap, or use a Composer-safe bootstrap entrypoint.

Downstream workaround

In wp-carpeta I had to require wordpress/agents-api, add a temporary root provide for automattic/agents-api, and run PHPUnit through a prepend that defines the test WordPress stubs before Composer autoload.